Description

In the Linux kernel, the following vulnerability has been resolved: net: lock the socket in sock_gettstamp() sk->sk_flags must only be changed while holding the socket lock, because sock_set_flag() and sock_reset_flag() use non atomic operations (__set_bit() and __clear_bit()). sock_gettstamp() is one of the last places where a bit of sk->sk_flags is changed from a syscall without owning the socket lock, through sock_enable_timestamp(sk, SOCK_TIMESTAMP). sk_set_memalloc() and sk_clear_memalloc() also change sk->sk_flags without the socket lock, but their callers (nbd, iscsi_tcp, 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 SIOCGSTAMPNS_NEW ioctl racing with bind() can cancel the SOCK_RCU_FREE bit that udp_lib_get_port() just set, because both threads perform a read-modify-write on the same word. CPU 0 (bind) CPU 1 (SIOCGSTAMPNS_NEW) -------------------------------- ---------------------------- read sk_flags = F read sk_flags = F compute F | BIT(SOCK_RCU_FREE) compute F | BIT(SOCK_TIMESTAMP) store F | BIT(SOCK_RCU_FREE) sk_add_node_rcu(sk, ...) store F | BIT(SOCK_TIMESTAMP) After the lost update, SOCK_RCU_FREE is clear while the socket is visible to lockless UDP receive lookups. sk_destruct() 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 ipv4_pktinfo_prepare+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 ipv4_pktinfo_prepare+0x30/0x410 udp_queue_rcv_one_skb+0x51c/0x1180 udp_unicast_rcv_skb+0x109/0x350 ip_protocol_deliver_rcu+0x14b/0x310 ip_local_deliver_finish+0x29d/0x390 ip_local_deliver+0x24d/0x2a0 Only grab the socket lock when SOCK_TIMESTAMP has to be set, to keep the common case lockless.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-10-06T09:18:17.360Z",
  "pubdate": "2026-10-06T09:18:17.360Z",
  "executiveSummary": "A race condition vulnerability exists in the Linux kernel within the socket management subsystem, specifically involving the modification of sk->sk_flags. This defect constitutes a concurrency-based vulnerability where improper synchronization leads to a potential Use-After-Free (UAF) scenario.\nThe vulnerability occurs because non-atomic bitwise operations on sk->sk_flags are performed without holding the mandatory socket lock. Attackers can exploit this via the SIOCGSTAMPNS_NEW ioctl, racing against internal socket configuration operations like bind().\nIf successful, the race leads to the clearing of critical state flags, such as SOCK_RCU_FREE. This results in the premature deallocation of socket objects while they are still referenced by RCU-protected lookups, leading to memory corruption and potential code execution or system instability.\nThe vulnerability affects the Linux kernel's networking stack, specifically impacting UDP socket handling. Exploitation requires local access to perform specific ioctl calls. Given the nature of kernel-level UAF, the risk to system integrity is high, as it can lead to arbitrary memory read/write primitives via kernel heap exploitation.",
  "technicalDetails": "The root cause of this vulnerability is the lack of proper synchronization when modifying the sk->sk_flags member of a socket structure. The kernel utilizes __set_bit() and __clear_bit() functions to update flag states, which are not atomic operations when applied to the same memory word simultaneously.\nThe specific vulnerable function is sock_gettstamp(), which triggers sock_enable_timestamp(sk, SOCK_TIMESTAMP) to modify socket flags without acquiring the socket lock. The socket lock is a mandatory primitive for serializing state changes that affect the object's lifecycle and memory management.\nAn attacker can trigger a race condition by initiating a SIOCGSTAMPNS_NEW ioctl concurrently with a bind() operation. The bind() operation may set the SOCK_RCU_FREE flag to ensure safe asynchronous memory cleanup, while the concurrent ioctl attempts to update other bits in the same word (sk_flags).\nBecause the read-modify-write operations are performed without locking, the update from the ioctl can overwrite the bit modification performed by the bind() operation. Specifically, if the ioctl operation commits its state after the bind operation has started but before it completes, the SOCK_RCU_FREE bit may be inadvertently cleared.\nThe loss of the SOCK_RCU_FREE bit indicates to the kernel that the socket object does not require an RCU grace period before being freed. Consequently, sk_destruct() is invoked immediately upon socket closure. If the networking receive path is currently traversing the socket via an RCU-protected lookup, the kernel will retain a pointer to the now-freed slab object.\nSubsequent attempts to access this memory result in a slab-use-after-free fault. The provided call stack trace highlights that the error triggers in ipv4_pktinfo_prepare(), which accesses the invalid pointer during an incoming UDP packet processing routine. This facilitates a privilege escalation vector or a kernel crash, depending on the kernel heap layout and the attacker's ability to reallocate the freed memory block with controlled data."
}