CVE-2026-68284 in Linux
Summary
by MITRE • 08/10/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability exists within the linux kernel's bpf subsystem, specifically in the tcp_bpf_sendmsg() function where improper handling of socket message corking leads to a use-after-free condition. This flaw manifests when multiple threads attempt concurrent sends on the same socket, creating a race condition that compromises memory safety. The core issue stems from how the function manages the msg_tx variable across sk_stream_wait_memory() calls, which temporarily release and reacquire socket locks during memory allocation operations.
The technical flaw occurs because tcp_bpf_sendmsg() maintains msg_tx across the sk_stream_wait_memory() function call, which drops the socket lock to allow other processes to run while waiting for memory. During this window, if another thread modifies psock->cork by setting it to NULL and freeing the cork structure, the subsequent comparison between msg_tx and psock->cork becomes invalid. This comparison is performed in the error path of the function to determine whether msg_tx references a local temporary message or a shared cork structure, but when multiple threads are involved, this check fails catastrophically.
The operational impact of this vulnerability is severe as it allows for arbitrary memory corruption that can lead to system instability or potential privilege escalation. The use-after-free condition reported by KASAN demonstrates that freed memory at address ffff88810c908800 is accessed after being deallocated, with the stack trace showing the problematic call sequence through sk_msg_free, tcp_bpf_sendmsg, and system sendto functions. This vulnerability directly relates to CWE-416 which describes use-after-free conditions, and can be mapped to ATT&CK technique T1059.007 for privilege escalation through kernel exploits.
The mitigation strategy involves modifying the comparison logic within tcp_bpf_sendmsg() to explicitly check whether msg_tx points to a stack-local temporary message rather than relying on the potentially stale psock->cork comparison. This change ensures that only legitimate local temporary messages are treated as such, preventing the erroneous free operation that occurs when a changed psock->cork incorrectly identifies freed memory as local. The fix requires careful consideration of thread safety and proper synchronization mechanisms to prevent race conditions while maintaining the function's intended behavior for legitimate use cases.