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