Look up another CVE · open CVE-2026-98276 in the interactive tracker
CVE-2026-98276
net: lock the socket in sock_gettstamp()
Published 2026-10-06 (13 days ago) by the Linux kernel CNA. Subsystem net/core. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-98276 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6568-1 · 2026-10-16 · text | 6.12.113-1 | Update the kernel and reboot. DSA-6568-1 shipped the fix on 2026-10-16, in 6.12.113-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.8-1 | Update the kernel and reboot. Fixed in 7.2.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.8-1 | Update the kernel and reboot. Fixed in 7.2.8-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/core/sock.c
- What this is
- NETWORKING [SOCKETS]MAINTAINERS section matched on net/core/*sock* · Maintained
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS Debian linux-config packages
Signals
- Published
- 2026-10-06 (13 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.14%, higher than 2.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/core
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 2.6.12 | 5.10.271 | 18899e2e4023 |
| 2.6.12 | 5.15.222 | 88c804847dd8 |
| 2.6.12 | 6.1.189 | 3b12d3967e96 |
| 2.6.12 | 6.6.158 | 17b2a1eb97fd |
| 2.6.12 | 6.12.112 | 1f73253add83 |
| 2.6.12 | 6.18.54 | d9f96bc2d822 |
| 2.6.12 | 7.2.8 | 899650bbf985 |
| 2.6.12 | 7.3 | 9ed55f3dbef4 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DSA-6568-1 | 2026-10-16 | trixie 6.12.113-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The lost update is caused by a local process racing the SIOCGSTAMP*/SIOCGSTAMPNS* ioctl (sock_ioctl -> sock_gettstamp -> sock_enable_timestamp) against bind() -> udp_lib_get_port() setting SOCK_RCU_FREE on its own UDP socket. No network message supplies the triggering state; remote packets only deliver into the already-corrupted socket.
- AC:LAttack complexity, low
- The attacker owns both sides of the race: one thread calls bind(), another calls the timestamp ioctl on the same fd. It can create, bind and close sockets in a loop until the __set_bit read-modify-write on sk_flags loses SOCK_RCU_FREE, then send loopback UDP to hit the freed sock.
- PR:LPrivileges required, low
- It only needs an ordinary AF_INET/AF_INET6 UDP socket. sock_ioctl's SIOCGSTAMP case and inet bind to an ephemeral or unprivileged port have no capability check, and the reporters reproduced it as UID 1000.
- UI:NUser interaction, none
- The attacker drives every step (socket creation, concurrent bind/ioctl, close, sending packets to its own port) with no action from any other user.
- S:UScope, unchanged
- The freed struct sock and the code that reads it are both in the same kernel; this is local kernel memory corruption that leads to privilege escalation inside one authority, with no VM or sandbox boundary crossed.
- C:HConfidentiality impact, high
- With SOCK_RCU_FREE lost, sk_destruct frees the UDP struct sock immediately while lockless RCU lookups in udp_unicast_rcv_skb/udp_queue_rcv_one_skb still hold a pointer to it. A slab UAF of a struct sock can be reclaimed with sprayed data to leak kernel memory.
- I:HIntegrity impact, high
- The receive path operates on the freed sock: it queues skbs, updates counters and reads sk_prot/sk_filter-related fields. If the attacker reclaims the slab, these become writes into, and function-pointer use from, attacker-controlled memory, which is a path to control-flow hijack.
- A:HAvailability impact, high
- Even when not exploited, the use-after-free in ipv4_pktinfo_prepare/udp_queue_rcv_one_skb (shown by KASAN) corrupts slab memory and can oops or panic the kernel.