CVE-2026-98432

Résumé

Dans le noyau Linux, la vulnérabilité suivante a été corrigée : ipv4 : libérer inet_opt et ireq_opt après une période de grâce RCU. tcp_v4_syn_recv_sock() transfère la propriété de ireq->ireq_opt au socket enfant (newinet->inet_opt) sans le copier. Un autre cpu peut traiter simultanément un SYN retransmis pour le même request socket, et envoyer un SYNACK depuis tcp_check_req(). tcp_v4_send_synack() et inet_csk_route_req() lisent ireq->ireq_opt uniquement sous rcu_read_lock(), puis ip_build_and_send_pkt() et ip_options_build() lisent opt->optlen deux fois. Notez que le timer SYNACK lui-même ne pose pas problème : il détient une référence sur son request socket, et inet_csk_reqsk_queue_drop() appelle timer_delete_sync() avant que l'enfant puisse être libéré. Depuis le commit 079096f103fa (« tcp/dccp: install syn_recv requests into ehash table »), les request sockets sont traités sans détenir le verrou du listener, donc rien n'empêche le socket enfant d'être libéré pendant que le SYNACK est encore en cours de construction. Les sockets enfants TCP n'ont pas SOCK_RCU_FREE, et inet_sock_destruct() libère inet_opt avec un simple kfree(), ce qui conduit à un use-after-free dans ip_options_build(). Un problème similaire existe avec la migration de request socket (net.ipv4.tcp_migrate_req=1, ou un programme BPF_SK_REUSEPORT_SELECT_OR_MIGRATE). reqsk_timer_handler() clone le request socket avec inet_reqsk_clone(), de sorte que l'ancien request socket et son clone partagent le même ireq_opt, puis reqsk_migrate_reset() efface le pointeur dans l'ancien. Un autre cpu détenant une référence sur l'ancien request socket peut encore utiliser ces options (en envoyant un SYNACK, ou en créant un enfant dans tcp_v4_syn_recv_sock()) lorsque le clone est libéré, et tcp_v4_reqsk_destructor() utilise également un simple kfree(). Les lecteurs utilisent déjà RCU, et d'autres chemins remplaçant inet_opt (do_ip_setsockopt(), cipso_v4_sock_setattr()...) utilisent déjà kfree_rcu(). Utilisez kfree_rcu() dans inet_sock_destruct() et tcp_v4_reqsk_destructor() également. IPv6 n'est pas affecté par le premier problème, car tcp_v6_syn_recv_sock() duplique les options. tcp_v6_reqsk_destructor() présente le même problème de migration avec ipv6_opt, qui n'est défini que par CALIPSO. Cela sera traité dans un patch séparé.

Sources

• kernel98scan