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

CVE-2026-64025 Overview

CVE-2026-64025 is a Linux kernel vulnerability in the BPF sockmap (skmsg) subsystem. The flaw creates a race between the BPF verdict path (sk_psock_verdict_data_ready) and the Kernel TLS (kTLS) receive path. When a socket is inserted into a sockmap with BPF_SK_SKB_VERDICT before TLS RX is configured, the verdict data-ready handler drains the socket receive queue without advancing copied_seq, corrupting kTLS strparser state. This results in a use-after-free when tls_decrypt_sg() walks a frag_list that points at psock-owned, potentially freed, socket buffers.

Critical Impact
A local attacker can trigger memory corruption in the Linux kernel, potentially leading to arbitrary code execution or denial of service.

Affected Products

Linux kernel versions containing the BPF sockmap and kTLS subsystems prior to the fix commits
Distributions shipping affected upstream kernels with CONFIG_BPF_SYSCALL and CONFIG_TLS enabled
Systems using BPF_SK_SKB_VERDICT programs on TCP sockets alongside kernel TLS

Discovery Timeline

2026-07-19 - CVE-2026-64025 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-64025

Vulnerability Analysis

The vulnerability stems from asymmetric handling between two BPF sockmap data-ready callbacks. sk_psock_strp_data_ready() correctly checks tls_sw_has_ctx_rx() and defers to psock->saved_data_ready when a TLS RX context is present. This preserves the TLS strparser's exclusive ownership of the receive queue, a fix originally introduced in commit e91de6afa81c.

However, sk_psock_verdict_data_ready() lacks the equivalent guard. When a socket enters a sockmap through BPF_SK_SKB_VERDICT before TLS RX initialization, tls_sw_strparser_arm() saves the verdict callback as rx_ctx->saved_data_ready. Subsequent data arrival triggers a corrupted control flow.

Root Cause

The root cause is a missing tls_sw_has_ctx_rx() check in sk_psock_verdict_data_ready(). On data arrival, the call chain executes tls_data_ready → tls_strp_data_ready → tls_rx_msg_ready → saved_data_ready(), which resolves to sk_psock_verdict_data_ready(). That function invokes tcp_read_skb(), which drains sk_receive_queue via __skb_unlink() without calling tcp_eat_skb(). The copied_seq counter is therefore not advanced.

tls_strp_msg_load() then observes tcp_inq() >= full_len from stale state and calls tcp_recv_skb() on the now-empty queue, hitting WARN_ON_ONCE(!first). The strparser's rx_ctx->strp.anchor.frag_list is left pointing at psock-owned skbs that may already have been freed. This is a classic use-after-free [CWE-416] with a race-condition [CWE-362] trigger.

Attack Vector

The vulnerability is triggered by loading a BPF_SK_SKB_VERDICT program and attaching a TCP socket to a sockmap before configuring kTLS on the same socket. When TLS records arrive, tls_decrypt_sg() walks the corrupted frag_list and dereferences freed skb memory. Exploitation requires the CAP_BPF or CAP_NET_ADMIN capability to install sockmap verdict programs, and the ability to establish a TLS session on the affected socket.

The fix mirrors the existing sk_psock_strp_data_ready() behavior: when a TLS RX context is detected, the verdict handler calls psock->saved_data_ready (sock_def_readable) to wake recv() waiters and returns immediately, leaving the receive queue untouched. TLS then retains sole ownership and decrypts records normally through tls_sw_recvmsg().

Detection Methods for CVE-2026-64025

Indicators of Compromise

Kernel WARN_ON_ONCE(!first) splats originating from tcp_recv_skb() invoked via tls_strp_msg_load()
Kernel oops or panic traces referencing tls_decrypt_sg, tls_strp_msg_load, or sk_psock_verdict_data_ready
KASAN use-after-free reports in the TLS receive path referencing freed sk_buff structures
Unexpected socket disconnections on TLS connections following sockmap program attachment

Detection Strategies

Audit loaded BPF programs for BPF_PROG_TYPE_SK_SKB with BPF_SK_SKB_VERDICT attach type using bpftool prog show
Correlate sockmap program attachment events with subsequent kTLS setsockopt(TLS_RX) calls on the same socket
Monitor dmesg and journald for kernel warnings referencing skmsg, tls_strp, or KASAN reports
Deploy tracing on sk_psock_verdict_data_ready and tls_sw_strparser_arm to identify vulnerable attach sequences

Monitoring Recommendations

Collect kernel version telemetry across the fleet and flag hosts running unpatched kernels
Alert on bpf() syscalls loading SK_SKB programs from non-privileged workloads or containers
Forward kernel crash artifacts and KASAN reports to a centralized log store for retrospective analysis
Track processes holding CAP_BPF or CAP_NET_ADMIN in container runtimes and orchestrators

How to Mitigate CVE-2026-64025

Immediate Actions Required

Apply the upstream kernel patches referenced in the stable tree commits (1861d369efd6, 7c8cf21bc4ef, 8a52139560f8, c9ea01768903, ddf8029623a1)
Update to a distribution kernel that includes the backported fix and reboot affected systems
Restrict CAP_BPF and CAP_NET_ADMIN capabilities in container and workload security policies
Inventory workloads that combine BPF sockmap verdict programs with kernel TLS termination

Patch Information

The fix adds a tls_sw_has_ctx_rx() check to sk_psock_verdict_data_ready(), aligning its behavior with sk_psock_strp_data_ready(). Reference the upstream commits: 1861d369efd6, 7c8cf21bc4ef, 8a52139560f8, c9ea01768903, and ddf8029623a1. Consult your distribution's advisory for the specific package version containing the backport.

Workarounds

Disable unprivileged BPF by setting kernel.unprivileged_bpf_disabled=1 via sysctl to reduce attack surface
Avoid combining BPF_SK_SKB_VERDICT sockmap programs with kernel TLS on the same sockets until patched
Enforce seccomp profiles that block the bpf() syscall for untrusted container workloads
Remove CAP_BPF and CAP_NET_ADMIN from workloads that do not require BPF program loading

bash

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

# Verify current kernel version against patched release
uname -r

# Enumerate SK_SKB BPF programs currently loaded
bpftool prog show | grep -i sk_skb