HIGH Introduced in 4.20
sockmap Cork UAF
CVE-2026-68284
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI7.0HIGH
01Description
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.
02KernelScan AI Analysis
Risk summary
A use-after-free in the BPF sockmap TCP send path allows a local attacker who can set up a sockmap to corrupt kernel heap memory, potentially leading to privilege escalation or kernel crash. Exploitation requires winning a race condition between two threads sending on the same socket. Products that run untrusted or multi-tenant workloads with BPF sockmap enabled are most at risk.
Vulnerability analysis
When a thread sending data on a TCP socket attached to a BPF sockmap fails to allocate memory, it waits for buffer space, temporarily releasing the socket lock. During this window, another thread sending on the same socket can complete and free the cork structure. When the first thread reacquires the lock and enters its error path, it compares its cached message pointer against the now-changed cork pointer and mistakenly concludes the freed cork is a local temporary message, freeing it again — a use-after-free. The fix changes the error-path check to directly test whether the pointer refers to the stack-local temporary message rather than inferring it by comparison against the shared cork, so a concurrently freed cork can no longer be mistaken for a local allocation. The vulnerability is reachable locally by any process that can send on a sockmap-attached socket with two concurrent threads; setting up the sockmap requires CAP_BPF.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 5.10 | 4.20 | 5.10.265 | 0688e6fe599d |
| mainline | 4.20 | 7.2 | 2d66a033864e |
| 6.1 | 4.20 | 6.1.183 | 54be47e7cbb9 |
| 7.1 | 4.20 | 7.1.6 | 752b1159ed5d |
| 5.15 | 4.20 | 5.15.216 | b2bcbeabfd84 |
| 6.12 | 4.20 | 6.12.101 | cde4d6bcd9b7 |
| 6.18 | 4.20 | 6.18.42 | 786d690257ec |
| 6.6 | 4.20 | 6.6.148 | ee762f684eef |