In the Linux kernel, the following vulnerability has been resolved: bpf, skmsg: fix verdict sk_data_ready racing with ktls rx… (CVE-2026-64025)
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().
AI Analysis
Technical Summary
The vulnerability (CVE-2026-64025) in the Linux kernel concerns the bpf, skmsg subsystem where sk_psock_verdict_data_ready() lacked a guard present in sk_psock_strp_data_ready() to defer to the TLS RX context's saved_data_ready callback. This omission caused a race condition when a socket was inserted into a sockmap before TLS RX was configured. On data arrival, the sk_receive_queue was drained without advancing the copied sequence number, leading to stale TCP queue state and a use-after-free when tls_decrypt_sg() accessed a freed skb fragment list. The patch applies the same guard as in sk_psock_strp_data_ready(), ensuring TLS retains sole ownership of the receive queue and preventing the use-after-free.
Potential Impact
This vulnerability can cause a use-after-free condition in the Linux kernel's networking stack during TLS receive processing with BPF socket verdict programs. Such a flaw may lead to kernel warnings, potential crashes, or memory corruption. No known exploits in the wild have been reported. The impact is limited to kernel stability and security related to TLS data handling and BPF socket verdict programs.
Mitigation Recommendations
A fix has been applied to the Linux kernel source code to address this issue by adding the necessary guard in sk_psock_verdict_data_ready(). Users should update their Linux kernel to a version that includes this patch. Since this is not a cloud service, remediation requires applying the official kernel update. Patch status is not explicitly confirmed in the provided data; users should consult the vendor or kernel mailing list advisories for the exact fixed versions and update accordingly.
In the Linux kernel, the following vulnerability has been resolved: bpf, skmsg: fix verdict sk_data_ready racing with ktls rx… (CVE-2026-64025)
Description
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 v3.1
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability (CVE-2026-64025) in the Linux kernel concerns the bpf, skmsg subsystem where sk_psock_verdict_data_ready() lacked a guard present in sk_psock_strp_data_ready() to defer to the TLS RX context's saved_data_ready callback. This omission caused a race condition when a socket was inserted into a sockmap before TLS RX was configured. On data arrival, the sk_receive_queue was drained without advancing the copied sequence number, leading to stale TCP queue state and a use-after-free when tls_decrypt_sg() accessed a freed skb fragment list. The patch applies the same guard as in sk_psock_strp_data_ready(), ensuring TLS retains sole ownership of the receive queue and preventing the use-after-free.
Potential Impact
This vulnerability can cause a use-after-free condition in the Linux kernel's networking stack during TLS receive processing with BPF socket verdict programs. Such a flaw may lead to kernel warnings, potential crashes, or memory corruption. No known exploits in the wild have been reported. The impact is limited to kernel stability and security related to TLS data handling and BPF socket verdict programs.
Mitigation Recommendations
A fix has been applied to the Linux kernel source code to address this issue by adding the necessary guard in sk_psock_verdict_data_ready(). Users should update their Linux kernel to a version that includes this patch. Since this is not a cloud service, remediation requires applying the official kernel update. Patch status is not explicitly confirmed in the provided data; users should consult the vendor or kernel mailing list advisories for the exact fixed versions and update accordingly.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-r22g-q228-2mx8
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-64025"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a5d27a92a4a8d598912c892
Added to database: 07/19/2026, 19:38:17 UTC
Last enriched: 07/19/2026, 19:54:25 UTC
Last updated: 07/20/2026, 19:56:56 UTC
Views: 12
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.