Look up another CVE · open CVE-2026-64025 in the interactive tracker
CVE-2026-64025
bpf, skmsg: fix verdict sk_data_ready racing with ktls rx
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem net/core. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-64025 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
sk_psock_strp_data_ready() already checks tls_sw_has_ctx_rx() and defers to psock->saved_data_ready when a TLS RX context is present, avoiding a conflict with the TLS strparser's ownership of the receive queue (commit e91de6afa81c, "bpf: Fix running sk_skb program types with ktls"). sk_psock_verdict_data_ready() has no equivalent guard. When a socket is inserted into a sockmap (BPF_SK_SKB_VERDICT) before TLS RX is configured, tls_sw_strparser_arm() saves sk_psock_verdict_data_ready as rx_ctx->saved_data_ready. On data arrival: tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready -> saved_data_ready() = sk_psock_verdict_data_ready() -> tcp_read_skb() drains sk_receive_queue via __skb_unlink() without calling tcp_eat_skb(), so copied_seq is not advanced. tls_strp_msg_load() then finds tcp_inq() >= full_len (stale), calls tcp_recv_skb() on the now-empty queue, hits WARN_ON_ONCE(!first), and returns with rx_ctx->strp.anchor.frag_list pointing at a psock-owned (potentially freed) skb. tls_decrypt_sg() subsequently walks that frag_list: use-after-free. Apply the same fix as sk_psock_strp_data_ready(): if a TLS RX context is present, call psock->saved_data_ready (sock_def_readable) to wake recv() waiters and return immediately, leaving the receive queue untouched. TLS retains sole ownership of the queue and decrypts the record normally through tls_sw_recvmsg().
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/core/skmsg.c
- What this is
- BPF [L7 FRAMEWORK] (sockmap)MAINTAINERS section matched on net/core/skmsg.c · netdev@vger.kernel.org · Maintained
Check it on the machine
grep -w CONFIG_NET_SOCK_MSG /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_NET_SOCK_MSG
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.34%, higher than 26.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/core
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.10 | 6.6.142 | c9ea01768903 |
| 5.10 | 6.12.92 | 7c8cf21bc4ef |
| 5.10 | 6.18.34 | 1861d369efd6 |
| 5.10 | 7.0.11 | 8a52139560f8 |
| 5.10 | 7.1 | ddf8029623a1 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- The UAF is triggered on the kTLS software RX path when a remote TLS peer sends TCP data; inbound network packets drive tls_data_ready through to sk_psock_verdict_data_ready and tls_decrypt_sg on internet-facing eBPF/kTLS proxy servers.
- AC:LAttack complexity, low
- Once the sockmap-before-TLS-RX configuration exists, the bug fires deterministically on the first arriving TLS record; the attacker controls packet delivery and timing without needing to win an uncontrollable race.
- PR:NPrivileges required, none
- A remote unauthenticated TLS client needs no privileges on the victim host to trigger the bug on a server already running BPF sockmap verdict with kTLS RX; local exploitation via user namespaces only raises the bar to CAP_NET_ADMIN/CAP_BPF (PR:L), not higher.
- UI:NUser interaction, none
- Exploitation requires only sending TLS traffic to a vulnerable socket; no victim user action such as opening files or mounting filesystems is needed.
- S:UScope, unchanged
- Impact is kernel heap corruption within the host kernel security boundary; it does not inherently cross VM, container, or IOMMU isolation boundaries without separate escalation.
- C:HConfidentiality impact, high
- The bug is a use-after-free where tls_decrypt_sg() walks a dangling skb frag_list via skb_to_sgvec/skb_copy_bits, enabling arbitrary kernel memory read primitives from attacker-influenced freed heap objects.
- I:HIntegrity impact, high
- Heap UAF over sk_buff structures in the TLS decrypt path can be leveraged for arbitrary kernel memory writes and control-flow hijacking, not merely a bounded or transient corruption.
- A:HAvailability impact, high
- The failure path hits WARN_ON_ONCE in tls_strp_load_anchor_with_queue and the UAF in tls_decrypt_sg can cause kernel oops, panic, or crash during softirq TLS receive processing.