Skip to main content
VulnerabilityPublished Updated

CVE-2026-64025: Linux kernel · Race Condition

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 9.8 Critical · fixed in ddf8029623a1af20e984c040e89ff918158397ab : patch Linux kernel as a priority.

Data as of 26 Oct 2026, 13:47 UTC

CVSS 3.1 base score
9.8Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.3% chance of exploitation in 30 days – higher than 27% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers can reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in ddf8029623a1af20e984c040e89ff918158397ab, c9ea01768903ae47f210cd457af1dead6de7a9c3, 1861d369efd62d67796563bf3e01fc22e5626f8b +2
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 19 Jul 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ ef5659280eb13e8ac31c296f58cfdfa1684ac06b, < ddf8029623a1af20e984c040e89ff918158397ab
Fixed in
  • ddf8029623a1af20e984c040e89ff918158397ab
LinuxLinuxAffected
  • ≥ ef5659280eb13e8ac31c296f58cfdfa1684ac06b, < c9ea01768903ae47f210cd457af1dead6de7a9c3
Fixed in
  • c9ea01768903ae47f210cd457af1dead6de7a9c3
LinuxLinuxAffected
  • ≥ ef5659280eb13e8ac31c296f58cfdfa1684ac06b, < 1861d369efd62d67796563bf3e01fc22e5626f8b
Fixed in
  • 1861d369efd62d67796563bf3e01fc22e5626f8b
LinuxLinuxAffected
  • ≥ ef5659280eb13e8ac31c296f58cfdfa1684ac06b, < 8a52139560f833c3975032e1f5762611e3a36d71
Fixed in
  • 8a52139560f833c3975032e1f5762611e3a36d71
LinuxLinuxAffected
  • ≥ ef5659280eb13e8ac31c296f58cfdfa1684ac06b, < 7c8cf21bc4efb4af18d6096db3f8bd06d622251c
Fixed in
  • 7c8cf21bc4efb4af18d6096db3f8bd06d622251c
LinuxLinuxAffected
  • =5.10
Fixed in–

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().

References

Community reviews

Loading reviews…