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