CVE-2026-64025

In the Linux kernel, the following vulnerability has been resolved:

bpf, skmsg: fix verdict skdataready racing with ktls rx

skpsockstrpdataready() already checks tlsswhasctxrx() and

defers to psock->saveddataready 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").

skpsockverdictdataready() has no equivalent guard.  When a socket

is inserted into a sockmap (BPFSKSKB_VERDICT) before TLS RX is

configured, tlsswstrparserarm() saves skpsockverdictdata_ready

as rxctx->saveddata_ready.  On data arrival:

  tlsdataready -> tlsstrpdataready -> tlsrxmsgready

    -> saveddataready() = skpsockverdictdataready()

      -> tcpreadskb() drains skreceivequeue via _skbunlink()

         without calling tcpeatskb(), so copied_seq is not advanced.

tlsstrpmsgload() then finds tcpinq() >= full_len (stale), calls

tcprecvskb() on the now-empty queue, hits WARNONONCE(!first), and

returns with rxctx->strp.anchor.fraglist pointing at a psock-owned

(potentially freed) skb.  tlsdecryptsg() subsequently walks that

frag_list: use-after-free.

Apply the same fix as skpsockstrpdataready(): if a TLS RX context

is present, call psock->saveddataready (sockdefreadable) 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 tlsswrecvmsg().