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

ipv4: free inetopt and ireqopt after an RCU grace period

tcpv4synrecvsock() transfers ownership of ireq->ireqopt to the child socket (newinet->inetopt) without copying it.

Another cpu can concurrently process a retransmitted SYN for the same request socket, and send a SYNACK from tcpcheckreq(). tcpv4sendsynack() and inetcskroutereq() read ireq->ireqopt under rcureadlock() only, and ipbuildandsendpkt() and ipoptionsbuild() then read opt->optlen twice.

Note that the SYNACK timer itself is not an issue: it holds a reference on its request socket, and inetcskreqskqueuedrop() calls timerdeletesync() before the child can be freed.

Since commit 079096f103fa ("tcp/dccp: install synrecv 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 SOCKRCUFREE, and inetsockdestruct() frees inetopt with a plain kfree(), leading to a use-after-free in ipoptionsbuild().

A similar issue exists with request socket migration (net.ipv4.tcpmigratereq=1, or a BPFSKREUSEPORTSELECTORMIGRATE program). reqsktimerhandler() clones the request socket with inetreqskclone(), so that the old request socket and its clone share the same ireqopt, then reqskmigratereset() 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 tcpv4synrecvsock()) when the clone is freed, and tcpv4reqskdestructor() also uses a plain kfree().

Readers already use RCU, and other paths replacing inetopt (doipsetsockopt(), cipsov4socksetattr()...) already use kfreercu(). Use kfreercu() in inetsockdestruct() and tcpv4reqskdestructor() as well.

IPv6 is not affected by the first issue, because tcpv6synrecvsock() duplicates the options. tcpv6reqskdestructor() has the same migration issue with ipv6opt, which is only set by CALIPSO. This will be addressed in a separate patch.

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

SUNRPC: fix gssxdecoptionarray error path bugs

Four coupled defects in the gssx XDR option-array decoder make the error paths unsafe: a NULL deref in the caller, a refcount leak on the decoded groupinfo, and a latent use-after-free that the leak fix would otherwise expose.

gssxdecoptionarray() sets oa->count = 1 before allocating oa->data. If that allocation fails, -ENOMEM is returned with oa->count == 1 and oa->data == NULL. All other error paths jump to freeoa: which frees oa->data and NULLs it but also leaves oa->count == 1. The caller trusts the count:

gsspacceptseccontextupcall() gssxdecacceptseccontext() gssxdecoptionarray() / fails, count=1 data=NULL / data = res.options.data[0].value / NULL deref /

Independently, freecreds: releases the partially decoded svccred with a bare kfree(creds). gssxdeclinuxcreds() installs a groupsalloc() result into creds->crgroupinfo; that object is kvmalloc-backed and refcounted, and only putgroupinfo() reaches kvfree(). A plain kfree(creds) drops the wrapper and leaks the groupinfo allocation.

The natural fix for the leak is to call freesvccred(creds) before kfree(creds), but freesvccred() invokes putgroupinfo() on creds->crgroupinfo unconditionally when non-NULL. The existing outfreegroups: path in gssxdeclinuxcreds() already called groupsfree() on that pointer without clearing it, so once freesvccred() is wired in, the subsequent putgroupinfo() would touch freed memory.

Fix all four together:

- Move the oa->count = 1 assignment below the oa->data allocation so it is never set when oa->data is NULL. - Reset oa->count to 0 at freeoa: so count and data stay coherent and the caller sees an empty option array. - Call freesvccred(creds) before kfree(creds) at freecreds: so the refcounted crgroupinfo is released. freesvccred() either NULL-guards each field explicitly (crgroupinfo has an if() check) or delegates to a helper that is NULL-safe itself (kfree for the string fields, gssmechput() which guards with if(gm) at gssmechswitch.c:342), so it is safe to call on a partially decoded svccred where only cruid/crgid/crgroupinfo have been written and everything else is zero from kzalloc. - In gssxdeclinuxcreds()'s outfreegroups: path, release crgroupinfo with putgroupinfo() rather than groupsfree() so the teardown matches freesvccred()'s refcount-aware path, and clear the pointer so a later freesvccred() on the same creds does not release it a second time.