CVE-2026-98276: Linux Kernel Timestamp Race Turns UDP bind() Into a Use-After-Free
An unlocked flag write in sock_gettstamp() lets a local user strip SOCK_RCU_FREE from a UDP socket and trigger a kernel use-after-free (CVSS 7.8).
A newly assigned Linux kernel vulnerability, CVE-2026-98276, shows how a single unprotected bit flip in the networking stack can turn an ordinary bind() call into a use-after-free. It carries a CVSS 3.1 base score of 7.8 (High). A local, unprivileged user can trigger it by racing two system calls against the same UDP socket.
What Went Wrong
Every kernel socket keeps a word of option bits in sk->sk_flags. The helpers that change those bits, sock_set_flag() and sock_reset_flag(), use non-atomic __set_bit() and __clear_bit() operations. They are only safe while the caller holds the socket lock.
sock_gettstamp() was one of the last places where a syscall changed sk_flags without that lock. When a program asks for a packet timestamp with the SIOCGSTAMPNS_NEW ioctl, the kernel calls sock_enable_timestamp(sk, SOCK_TIMESTAMP) and does a read-modify-write on the flags word while holding no lock at all.
How the Race Becomes a Use-After-Free
Binding a UDP socket goes through udp_lib_get_port(). That function sets SOCK_RCU_FREE before it publishes the socket into the hash table that lockless receive lookups use. The flag tells the kernel to wait for an RCU grace period before freeing the socket, so readers on the receive path that hold a pointer without a reference stay safe.
If the timestamp ioctl runs on a second CPU at the same moment, both threads read the same original flags value. Each sets its own bit and writes the whole word back. When the ioctl's store lands last, it erases SOCK_RCU_FREE. The socket is now visible to lockless receive lookups, but it is marked to be freed immediately. When it is closed, sk_destruct() releases the memory at once while an incoming packet may still be using it.
The researchers who found the flaw showed the result with a KASAN report: a slab use-after-free read in ipv4_pktinfo_prepare(), reached through the normal UDP receive path. Their proof of concept ran as an ordinary user (UID 1000), not as root.
Who Is Exposed
The bug lives in core socket code, not in an optional driver, so it affects mainstream distribution kernels until they ship the fix. The trigger needs nothing special: a UDP socket, bind() and a timestamp ioctl, all available to any local process. Systems that run untrusted local code are most at risk, including shared hosts, CI runners, multi-tenant containers and developer workstations.
The current EPSS estimate is low, and there are no reports of exploitation in the wild. Even so, kernel use-after-free bugs reachable by unprivileged users are classic building blocks for privilege escalation and container escape. Major distributions are tracking the issue, and live-patch vendors have fixes in progress for releases such as Debian 12 and 13.
The Fix
The upstream patch makes sock_gettstamp() take the socket lock before it changes sk_flags. To keep the common path fast, the lock is only taken when SOCK_TIMESTAMP actually needs to be set. Once the timestamp flag is on, later calls do not pay for the lock.
The kernel maintainers also pointed out that sk_set_memalloc() and sk_clear_memalloc() change sk_flags without the socket lock. Their callers include nbd, iscsi_tcp, nvme-tcp, sunrpc and WireGuard. Those paths will get their own audit and a separate patch, so more fixes in this area are likely.
What To Do
- Install your distribution's kernel update that includes the "net: lock the socket in sock_gettstamp()" fix, and reboot or apply it through your live-patching service.
- Prioritise hosts where untrusted users or workloads can run code locally: shared servers, build agents, Kubernetes nodes and lab machines.
- Track your vendor's advisory for CVE-2026-98276, because backport status differs between stable kernel branches and distributions.
- Watch for follow-up patches covering the
sk_set_memalloc()callers, especially on storage and VPN hosts that use nvme-tcp, iSCSI, NBD or WireGuard. - Keep kernel crash and KASAN-style warnings in your monitoring, since repeated socket-related oopses on a multi-user host can be a sign of exploitation attempts.
Bottom Line
CVE-2026-98276 is a quiet bug with a sharp edge: two threads write back one word of flags and a socket loses its RCU protection. It is not remotely exploitable, but for any machine that runs code from more than one trust level, it belongs on this month's patch list.
