CVE-2026-68284: Linux Kernel Use-After-Free Vulnerability

CVE-2026-68284 Overview

CVE-2026-68284 is a use-after-free vulnerability in the Linux kernel's BPF sockmap subsystem, specifically in the tcp_bpf_sendmsg() function. The flaw stems from an unsafe pointer comparison across a socket lock release window in sk_stream_wait_memory(). When two threads send on the same socket concurrently, one thread can free a shared cork message while another thread still holds a stale reference to it. The stale pointer is then mistakenly identified as a local temporary message and freed a second time, triggering a slab use-after-free condition detected by KASAN.

Critical Impact
A local, authenticated attacker able to run BPF sockmap workloads can trigger kernel heap corruption, leading to denial of service or potential local privilege escalation.

Affected Products

Linux kernel versions containing the vulnerable tcp_bpf_sendmsg() implementation in the BPF sockmap subsystem
Distributions shipping affected upstream kernels with CONFIG_BPF_SYSCALL and sockmap enabled
Systems where unprivileged users can create BPF sockmap-enabled sockets

Discovery Timeline

2026-08-10 - CVE-2026-68284 published to NVD
2026-08-13 - Last updated in NVD database

Technical Details for CVE-2026-68284

Vulnerability Analysis

The defect resides in tcp_bpf_sendmsg() within the kernel's BPF sockmap code path. The function operates on a message pointer msg_tx that may reference either a stack-local temporary message (tmp) or a shared psock->cork structure. During execution, sk_stream_wait_memory() drops and reacquires the socket lock to wait for send buffer space.

While the lock is released, another thread on the same socket can complete its own cork, set psock->cork = NULL, and free the underlying memory. When the original thread resumes, its error path compares msg_tx against the current psock->cork to decide whether msg_tx is the local temporary. Because psock->cork has changed, the shared cork pointer is misclassified as local and passed to sk_msg_free(), producing a slab use-after-free.

Root Cause

The root cause is a race condition combined with an unsafe identity check across a lock release. The comparison msg_tx != psock->cork is not a reliable proof that msg_tx names the stack-local tmp, because psock->cork is mutable while the socket lock is released. This is a classic time-of-check to time-of-use (TOCTOU) pattern that yields double-free and use-after-free semantics on the shared cork allocation.

Attack Vector

Exploitation requires local code execution and the ability to open sockets attached to a BPF sockmap. An attacker runs two concurrent sendto() threads against the same sockmap-attached TCP socket. One thread must enter sk_stream_wait_memory() after sk_msg_alloc() fails, while the second thread completes an active cork and frees it. The resulting sk_msg_free() call on the freed cork corrupts the SLAB allocator state, which can be shaped into kernel memory disclosure or control-flow hijacking. KASAN captures the primitive as a slab-use-after-free read of size 4 at the freed cork address inside sk_msg_free+0x49/0x50.

No public proof-of-concept exploit is listed for CVE-2026-68284 in the referenced advisories. Technical details are available in the upstream Linux kernel commits linked under references.

Detection Methods for CVE-2026-68284

Indicators of Compromise

KASAN reports of slab-use-after-free in sk_msg_free with call stacks traversing tcp_bpf_sendmsg and __sys_sendto
Kernel oops or panic entries referencing sk_msg_free, tcp_bpf_sendmsg, or corrupted psock->cork state
Unexpected process termination or kernel task hangs on hosts running BPF sockmap workloads

Detection Strategies

Enable KASAN on non-production kernels and monitor dmesg for use-after-free reports touching sk_msg_free and tcp_bpf_sendmsg
Audit loaded BPF programs with bpftool prog show and bpftool map show to enumerate sockmap and sockhash consumers
Correlate sendto() syscall bursts from the same PID against sockmap-attached sockets in EDR telemetry

Monitoring Recommendations

Log and alert on unprivileged processes creating BPF_MAP_TYPE_SOCKMAP or BPF_MAP_TYPE_SOCKHASH maps
Monitor kernel ring buffer for BUG:, KASAN:, and general protection fault entries and forward to a central SIEM
Track kernel version and patch state across the fleet to prioritize hosts still exposed to the flaw

How to Mitigate CVE-2026-68284

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the commits 2d66a03, 752b115, 786d690, cde4d6bc, and ee762f68
Update to a distribution kernel package that includes the backported fix for tcp_bpf_sendmsg()
Restrict CAP_BPF and CAP_NET_ADMIN to trusted service accounts to reduce the local attack surface

Patch Information

The fix changes the cork identification logic in tcp_bpf_sendmsg() to check whether msg_tx points at the stack-local tmp message directly, rather than comparing against the mutable psock->cork. This prevents a changed psock->cork from turning a shared cork into an apparent local message. Refer to the upstream commits: Linux Kernel Commit 2d66a03, Linux Kernel Commit 752b115, Linux Kernel Commit 786d690, Linux Kernel Commit cde4d6bc, and Linux Kernel Commit ee762f68.

Workarounds

Set kernel.unprivileged_bpf_disabled=1 via sysctl to block unprivileged users from loading BPF programs
Remove or restrict sockmap-based traffic redirection features on hosts where they are not required
Enforce seccomp filters that block the bpf() syscall for workloads that do not need it

bash

# Configuration example
# Disable unprivileged BPF program loading
sudo sysctl -w kernel.unprivileged_bpf_disabled=1
echo 'kernel.unprivileged_bpf_disabled=1' | sudo tee /etc/sysctl.d/90-bpf-hardening.conf

# Verify current kernel version and applied patches
uname -r
grep -E 'tcp_bpf_sendmsg|sk_msg_free' /proc/kallsyms | head