PT-2026-61342 · Linux · Linux
CVE-2026-64025
·
Published
2026-07-19
·
Updated
2026-07-19
CVSS v3.1
9.8
Critical
| Vector | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
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().
Fix
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux