CVE-2026-98276: net: lock the socket in sock_gettstamp()
In the Linux kernel, the following vulnerability has been resolved:
net: lock the socket in sockgettstamp()
sk->skflags must only be changed while holding the socket lock, because socksetflag() and sockresetflag() use non atomic operations (setbit() and clearbit()).
sockgettstamp() is one of the last places where a bit of sk->skflags is changed from a syscall without owning the socket lock, through sockenabletimestamp(sk, SOCKTIMESTAMP).
sksetmemalloc() and skclearmemalloc() also change sk->skflags without the socket lock, but their callers (nbd, iscsitcp, nvme-tcp, sunrpc, wireguard) need a careful audit, this will be addressed in a separate patch.
Jungwoo Lee and Wongi Lee reported an UDP socket use-after-free caused by this bug: a SIOCGSTAMPNSNEW ioctl racing with bind() can cancel the SOCKRCUFREE bit that udplibgetport() just set, because both threads perform a read-modify-write on the same word.
CPU 0 (bind) CPU 1 (SIOCGSTAMPNSNEW) -------------------------------- ---------------------------- read skflags = F read skflags = F compute F | BIT(SOCKRCUFREE) compute F | BIT(SOCKTIMESTAMP) store F | BIT(SOCKRCUFREE) skaddnodercu(sk, ...) store F | BIT(SOCKTIMESTAMP)
After the lost update, SOCKRCUFREE is clear while the socket is visible to lockless UDP receive lookups. skdestruct() then frees the socket immediately instead of waiting for a RCU grace period, while the receive path still holds a reference-less pointer to it:
BUG: KASAN: slab-use-after-free in ipv4pktinfoprepare+0x30/0x410 Read of size 8 at addr ffff888008806610 by task exploit/207 CPU: 0 UID: 1000 PID: 207 Comm: exploit Not tainted 6.12.95+ #1 ipv4pktinfoprepare+0x30/0x410 udpqueuercvoneskb+0x51c/0x1180 udpunicastrcvskb+0x109/0x350 ipprotocoldeliverrcu+0x14b/0x310 iplocaldeliverfinish+0x29d/0x390 iplocaldeliver+0x24d/0x2a0
Only grab the socket lock when SOCKTIMESTAMP has to be set, to keep the common case lockless.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch net: lock the socket in sock_gettstamp()
Event History
Frequently Asked Questions
What conditions are required to trigger the use-after-free?
An attacker needs local access and privileges sufficient to operate on a UDP socket. The reported race occurs when a SIOCGSTAMPNS_NEW ioctl runs concurrently with bind() on the same socket.
What is the underlying race condition?
sock_gettstamp() enabled SOCK_TIMESTAMP without holding the socket lock, while bind() could set SOCK_RCU_FREE. Because these flag updates use non-atomic read-modify-write operations, the timestamp operation can overwrite and cancel the SOCK_RCU_FREE flag, leading to a UDP socket use-after-free.
Are other sk_flags updates covered by this fix?
No. The description identifies sk_set_memalloc() and sk_clear_memalloc() as other paths that modify sk->sk_flags without the socket lock, and states that their callers require a separate careful audit and patch.