CVE-2026-64025: bpf, skmsg: fix verdict sk_data_ready racing with ktls rx

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 skskb program types with ktls").

skpsockverdictdataready() has no equivalent guard. When a socket is inserted into a sockmap (BPFSKSKBVERDICT) before TLS RX is configured, tlsswstrparserarm() saves skpsockverdictdataready as rxctx->saveddataready. On data arrival:

tlsdataready -> tlsstrpdataready -> tlsrxmsgready -> saveddataready() = skpsockverdictdataready() -> tcpreadskb() drains skreceivequeue via skbunlink() without calling tcpeatskb(), so copiedseq is not advanced.

tlsstrpmsgload() then finds tcpinq() >= fulllen (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 fraglist: 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().