CVE-2026-98432

In the Linux kernel, the following vulnerability has been resolved:

ipv4: free inet opt and ireq opt after an RCU grace period

tcp v4 syn recv sock() transfers ownership of ireq->ireq opt to the child socket (newinet->inet opt) without copying it.

Another cpu can concurrently process a retransmitted SYN for the same request socket, and send a SYNACK from tcp check req(). tcp v4 send synack() and inet csk route req() read ireq->ireq opt under rcu read lock() only, and ip build and send pkt() and ip options build() then read opt->optlen twice.

Note that the SYNACK timer itself is not an issue: it holds a reference on its request socket, and inet csk reqsk queue drop() calls timer delete sync() before the child can be freed.

Since commit 079096f103fa ("tcp/dccp: install syn recv requests into ehash table"), request sockets are processed without holding the listener lock, so nothing prevents the child socket from being freed while the SYNACK is still being built. TCP child sockets do not have SOCK RCU FREE, and inet sock destruct() frees inet opt with a plain kfree(), leading to a use-after-free in ip options build().

A similar issue exists with request socket migration (net.ipv4.tcp migrate req=1, or a BPF SK REUSEPORT SELECT OR MIGRATE program). reqsk timer handler() clones the request socket with inet reqsk clone(), so that the old request socket and its clone share the same ireq opt, then reqsk migrate reset() clears the pointer in the old one. Another cpu holding a reference on the old request socket can still be using these options (sending a SYNACK, or creating a child in tcp v4 syn recv sock()) when the clone is freed, and tcp v4 reqsk destructor() also uses a plain kfree().

Readers already use RCU, and other paths replacing inet opt (do ip setsockopt(), cipso v4 sock setattr()...) already use kfree rcu(). Use kfree rcu() in inet sock destruct() and tcp v4 reqsk destructor() as well.

IPv6 is not affected by the first issue, because tcp v6 syn recv sock() duplicates the options. tcp v6 reqsk destructor() has the same migration issue with ipv6 opt, which is only set by CALIPSO. This will be addressed in a separate patch.