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.
Published: 2026-10-06
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Analysis and contextual insights are available on OpenCVE Cloud.

Remediation

No vendor fix or workaround currently provided.

Additional remediation guidance may be available on OpenCVE Cloud.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 06 Oct 2026 19:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-416

Tue, 06 Oct 2026 17:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-416

Tue, 06 Oct 2026 15:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-416

Tue, 06 Oct 2026 09:00:00 +0000

Type Values Removed Values Added
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.
Title net: lock the socket in sock_gettstamp()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-06T08:45:36.837Z

Reserved: 2026-09-25T10:25:14.334Z

Link: CVE-2026-98276

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-06T09:18:17.360

Modified: 2026-10-06T09:18:17.360

Link: CVE-2026-98276

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-06T19:15:04Z

Weaknesses