CVE-2026-64025

What it actually does

This is a Linux kernel use-after-free in the interaction between BPF sockmap/skmsg verdict handling and kernel TLS receive processing. When a socket is placed in a sockmap with a BPF_SK_SKB_VERDICT program before TLS RX is configured, the TLS receive path can later call sk_psock_verdict_data_ready() as a saved data-ready callback. That callback can drain the TCP receive queue in a way that does not advance TCP copied sequence state, leaving the TLS strparser with stale queue accounting and a frag_list reference to an skb that is no longer owned by TLS and may already be freed. Subsequent TLS decryption can dereference freed memory in kernel context. Depending on allocator state and exploitability on a given kernel build, the result can range from kernel warning or crash to potential privilege escalation or remote code execution in kernel context where an attacker can drive the vulnerable socket state and network input.

Why it matters to the business

Successful exploitation can compromise the confidentiality, integrity, and availability of systems running affected Linux kernels. The most immediate operational risk is kernel panic or service disruption on hosts using kernel TLS together with BPF sockmap/skmsg verdict programs, such as high-performance proxies, service meshes, load balancers, security agents, or custom networking components. Because the flaw is in the kernel, a reliable exploit could allow full host compromise. It is not currently listed in CISA KEV, has no known public exploit maturity in the supplied data, and has a low EPSS score, but the CVSS severity is critical and the affected code sits in a high-value privilege boundary, so patching should be prioritized for internet-facing or multi-tenant Linux systems and any systems using eBPF networking features.

How an attack unfolds

An attacker must cause traffic to reach a socket that is both associated with a BPF sockmap verdict path and later configured for kernel TLS receive processing, or must have sufficient local privileges to create that state directly. The vulnerable ordering is important: the socket is inserted into a sockmap with a BPF_SK_SKB_VERDICT program before TLS RX is armed. When TLS data arrives, the TLS data-ready path invokes the saved BPF psock verdict data-ready callback. That callback consumes sk_buffs from the TCP receive queue without updating the sequence bookkeeping expected by the TLS strparser. TLS then believes a full record is still available, attempts to load from an empty or inconsistent receive queue, and retains a pointer to skb memory that BPF psock handling may own or free. When TLS decryption later walks that stale frag_list, the kernel dereferences freed memory. A denial-of-service exploit would attempt to make this path deterministic and crash the kernel; a more advanced exploit would groom kernel heap allocations around freed skb objects to convert the use-after-free into controlled memory corruption.

How to fix it

Upgrade to a Linux kernel package from the relevant distribution or vendor that includes the fix for the BPF skmsg verdict data-ready race with kTLS RX. No exact fixed package versions were provided in the input, so use vendor advisories for the deployed kernel stream and confirm the patch containing the sk_psock_verdict_data_ready TLS RX guard is present. A reboot into the fixed kernel is required unless the vendor provides a supported live patch. If immediate patching is not possible, reduce exposure by avoiding the affected feature combination: do not attach BPF_SK_SKB_VERDICT sockmap programs to sockets that will use kernel TLS RX, disable or avoid kTLS acceleration for affected services where feasible, and remove unneeded eBPF networking components. As defense in depth, restrict BPF program loading to trusted administrators only, disable unprivileged BPF where supported using kernel.unprivileged_bpf_disabled=1, remove CAP_BPF/CAP_NET_ADMIN from containers and services that do not require them, and limit access to workloads that can configure sockmaps or kTLS.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated and the host has rebooted into the fixed version. Validate with uname -a, distribution package tools, and vendor advisory metadata. Where source or build metadata is available, confirm the kernel includes the change that makes sk_psock_verdict_data_ready() defer to the saved data_ready callback when a TLS RX context is present, preserving TLS ownership of the receive queue. Review whether kTLS is enabled or loaded and whether BPF sockmap/skmsg verdict programs are in use by checking service configuration, bpftool output, loaded BPF programs/maps, and container capabilities. For exposure testing, identify systems running services that combine TLS offload/kTLS with eBPF sockmap acceleration. Avoid attempting destructive proof-of-concept testing on production systems because successful triggering may panic the kernel.

Typical attack path

1. Identify or gain access to a Linux system running an affected kernel with BPF sockmap/skmsg verdict functionality and kernel TLS receive support in use.
2. Establish or influence a TCP connection that is inserted into a sockmap with a BPF_SK_SKB_VERDICT program before TLS RX context is configured.
3. Send crafted or carefully timed TLS application data so the TLS receive callback path is invoked while the psock verdict data-ready callback remains saved in the TLS RX context.
4. Trigger sk_psock_verdict_data_ready() from the TLS data-ready path, causing TCP receive queue sk_buffs to be unlinked in a way that leaves TLS sequence and queue state inconsistent.
5. Cause TLS strparser/decryption code to process a stale frag_list entry referencing an skb that has been freed or transferred to psock ownership.
6. Leverage the resulting use-after-free to crash the kernel or, with heap grooming and kernel-specific primitives, attempt code execution or privilege escalation.

How to detect it

Look for signs of kernel memory corruption or crashes around the TLS receive path and BPF sockmap handling. Useful sources include journald, syslog, dmesg, kernel crash dumps, pstore/ramoops, hypervisor reset events, EDR kernel panic telemetry, and any KASAN/KMSAN reports from debug kernels. Search for warnings or stack traces involving tls_decrypt_sg, tls_strp_msg_load, tls_strp_data_ready, tls_rx_msg_ready, sk_psock_verdict_data_ready, tcp_read_skb, tcp_recv_skb, __skb_unlink, sk_msg, sockmap, or BPF_SK_SKB_VERDICT. Review BPF telemetry with bpftool for sockmap or sockhash maps and SK_SKB verdict programs loaded near the time of a crash. Correlate crashes with bursts of inbound TLS traffic to services known to use kTLS or eBPF networking acceleration. For potential malicious local setup, investigate recent BPF program loads, privileged container starts, processes with CAP_BPF or CAP_NET_ADMIN, and changes to services that attach sockets to sockmaps. Absence of these artifacts does not prove non-exploitation, because a successful kernel memory corruption attempt may leave only a panic or reset.

• BUG: KASAN: use-after-free in tls_decrypt_sg
• KASAN: use-after-free
• WARNING: CPU:
• tls_decrypt_sg
• tls_strp_msg_load
• tls_strp_data_ready
• tls_rx_msg_ready
• sk_psock_verdict_data_ready
• tcp_read_skb
• tcp_recv_skb
• __skb_unlink
• BPF_SK_SKB_VERDICT
• sockmap
• sockhash
• net/tls/tls_strp.c
• net/tls/tls_sw.c
• net/core/skmsg.c
• general protection fault
• kernel panic
• Oops:
• RIP: tls_decrypt_sg
• RIP: tls_strp_msg_load
• RIP: sk_psock_verdict_data_ready

What your security team should do

• Prioritize patching Linux kernels on internet-facing, high-availability, and multi-tenant systems, especially those running eBPF-based networking, proxies, service meshes, load balancers, or kTLS-enabled workloads.
• Create an asset query for hosts with kTLS support and BPF sockmap/skmsg verdict programs in use; treat those as the highest-risk subset.
• Disable unprivileged BPF and remove unnecessary CAP_BPF, CAP_NET_ADMIN, and privileged-container access to reduce the ability of local users or workloads to construct the vulnerable state.
• If patching must be delayed, temporarily disable kTLS acceleration or the BPF sockmap verdict functionality for affected services where operationally acceptable.
• Monitor kernel logs for TLS strparser warnings, KASAN use-after-free reports, general protection faults, or kernel panics involving tls_decrypt_sg, tls_strp_msg_load, sk_psock_verdict_data_ready, or tcp_recv_skb.
• Use bpftool or equivalent endpoint telemetry to baseline and alert on unexpected BPF_SK_SKB_VERDICT programs, sockmap/sockhash maps, or new BPF program loads by untrusted processes.
• Because there is no supplied evidence of known exploitation or KEV listing and EPSS is low, balance emergency change risk against exposure, but do not defer remediation on systems matching the vulnerable feature combination.