{"id":39867,"date":"2026-10-16T04:34:02","date_gmt":"2026-10-15T20:34:02","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-98432"},"modified":"2026-10-16T04:34:02","modified_gmt":"2026-10-15T20:34:02","slug":"cve-2026-98432","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-98432","title":{"rendered":"CVE-2026-98432 &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nipv4: free inet_opt a"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>ipv4: free inet_opt and ireq_opt after an RCU grace period<\/p>\n<p>tcp_v4_syn_recv_sock() transfers ownership of ireq-&gt;ireq_opt to the<br \/>\nchild socket (newinet-&gt;inet_opt) without copying it.<\/p>\n<p>Another cpu can concurrently process a retransmitted SYN for the same<br \/>\nrequest socket, and send a SYNACK from tcp_check_req().<br \/>\ntcp_v4_send_synack() and inet_csk_route_req() read ireq-&gt;ireq_opt<br \/>\nunder rcu_read_lock() only, and ip_build_and_send_pkt() and<br \/>\nip_options_build() then read opt-&gt;optlen twice.<\/p>\n<p>Note that the SYNACK timer itself is not an issue: it holds a<br \/>\nreference on its request socket, and inet_csk_reqsk_queue_drop()<br \/>\ncalls timer_delete_sync() before the child can be freed.<\/p>\n<p>Since commit 079096f103fa (&#8220;tcp\/dccp: install syn_recv requests<br \/>\ninto ehash table&#8221;), request sockets are processed without holding<br \/>\nthe listener lock, so nothing prevents the child socket from being<br \/>\nfreed while the SYNACK is still being built. TCP child sockets do<br \/>\nnot have SOCK_RCU_FREE, and inet_sock_destruct() frees inet_opt<br \/>\nwith a plain kfree(), leading to a use-after-free in<br \/>\nip_options_build().<\/p>\n<p>A similar issue exists with request socket migration<br \/>\n(net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE<br \/>\nprogram). reqsk_timer_handler() clones the request socket with<br \/>\ninet_reqsk_clone(), so that the old request socket and its clone<br \/>\nshare the same ireq_opt, then reqsk_migrate_reset() clears the<br \/>\npointer in the old one. Another cpu holding a reference on the old<br \/>\nrequest socket can still be using these options (sending a SYNACK,<br \/>\nor creating a child in tcp_v4_syn_recv_sock()) when the clone is<br \/>\nfreed, and tcp_v4_reqsk_destructor() also uses a plain kfree().<\/p>\n<p>Readers already use RCU, and other paths replacing inet_opt<br \/>\n(do_ip_setsockopt(), cipso_v4_sock_setattr()&#8230;) already use<br \/>\nkfree_rcu(). Use kfree_rcu() in inet_sock_destruct() and<br \/>\ntcp_v4_reqsk_destructor() as well.<\/p>\n<p>IPv6 is not affected by the first issue, because tcp_v6_syn_recv_sock()<br \/>\nduplicates the options. tcp_v6_reqsk_destructor() has the same<br \/>\nmigration issue with ipv6_opt, which is only set by CALIPSO. This<br \/>\nwill be addressed in a separate patch.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>ipv4: free inet_opt and ireq_opt after an RCU grace period<\/p>\n<p>tcp_v4_syn_recv_sock() transfers ownership of ireq-&gt;ireq_opt to the<br \/>\nchi<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-39867","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/39867","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=39867"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=39867"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=39867"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}