CVE-2026-68284

What it actually does

Use-after-free in tcp_bpf_sendmsg() caused by a stale pointer to a shared cork message after a concurrent thread frees it while the socket lock is dropped during sk_stream_wait_memory(); the error path incorrectly decides to free the message again based on a now-invalid comparison against psock->cork.

Why it matters to the business

Local attackers on multi-threaded or multi-process workloads using BPF sockmap can trigger kernel crashes or memory corruption on affected Linux systems, leading to denial of service or potential escalation; low EPSS and no KEV listing reduce immediate external risk but the 76-day publication window still requires prompt patching on exposed hosts.

How an attack unfolds

An attacker with local access crafts concurrent send operations on a socket using BPF sockmap so that one thread's allocation failure path races with another thread completing and freeing the cork; the first thread then dereferences the freed slab object inside sk_msg_free, producing the KASAN-detected slab-use-after-free.

How to fix it

Update the Linux kernel to a version containing the upstream fix for the cork comparison logic in tcp_bpf_sendmsg; apply the patch that checks the stack-local temporary message directly instead of relying on psock->cork.

How to confirm the fix worked

Confirm the kernel source contains the corrected comparison that checks the local tmp message directly; recompile, boot the new kernel, and run concurrency tests exercising tcp_bpf_sendmsg under KASAN or similar memory debuggers to verify absence of the use-after-free.

Typical attack path

1. Obtain local code execution on a Linux host using BPF sockmap with tcp_bpf_sendmsg paths
2. Create two threads that send on the same socket simultaneously
3. Force sk_msg_alloc failure in one thread to enter the sk_stream_wait_memory error path
4. Allow the second thread to finish the cork and free the shared message while the lock is dropped
5. Reacquire the lock and trigger the unsafe comparison that leads to double-free of the stale pointer

How to detect it

Search kernel logs and KASAN reports for sk_msg_free calls originating from tcp_bpf_sendmsg under slab-use-after-free conditions; inspect audit logs for concurrent sendto syscalls on sockets attached to BPF sockmap programs.

What your security team should do

• Prioritize kernel updates on any system exposing BPF sockmap to untrusted local users
• Monitor upstream stable branches for the exact commit that replaces the psock->cork comparison
• Temporarily restrict unprivileged BPF programs or sockmap usage if patching is delayed
• Include sockmap-related workloads in regression testing after kernel upgrades