CVE-2026-64025bpf, skmsg: fix verdict sk_data_ready racing with ktls rx
Updated under an hour ago ()
Does this affect you?
It affects Linux and 1 other product. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
In the Linux kernel, the following vulnerability has been resolved: bpf, skmsg: fix verdict sk_data_ready racing with ktls rx 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().
- CVSS
- 9.8 CRITICAL (v3.1, CNA)CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Analyzed
- Record last updated
- Oct 16, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from ef5659280eb13e8ac31c296f58cfdfa1684ac06b before c9ea01768903ae47f210cd457af1dead6de7a9c3; from ef5659280eb13e8ac31c296f58cfdfa1684ac06b before 7c8cf21bc4efb4af18d6096db3f8bd06d622251c; from ef5659280eb13e8ac31c296f58cfdfa1684ac06b before 1861d369efd62d67796563bf3e01fc22e5626f8b; from ef5659280eb13e8ac31c296f58cfdfa1684ac06b before 8a52139560f833c3975032e1f5762611e3a36d71; from ef5659280eb13e8ac31c296f58cfdfa1684ac06b before ddf8029623a1af20e984c040e89ff918158397ab | CNA record |
linux linux_kernel linux:linux_kernel | from 5.10 before 6.6.142; from 6.7 before 6.12.92; from 6.13 before 6.18.34; from 6.19 before 7.0.11; 7.1; 7.1; 7.1; 7.1 | NVD |
References
- https://git.kernel.org/stable/c/c9ea01768903ae47f210cd457af1dead6de7a9c3patch
- https://git.kernel.org/stable/c/7c8cf21bc4efb4af18d6096db3f8bd06d622251cpatch
- https://git.kernel.org/stable/c/1861d369efd62d67796563bf3e01fc22e5626f8bpatch
- https://git.kernel.org/stable/c/8a52139560f833c3975032e1f5762611e3a36d71patch
- https://git.kernel.org/stable/c/ddf8029623a1af20e984c040e89ff918158397abpatch
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.