CVE-2026-31533

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption<br /> <br /> The -EBUSY handling in tls_do_encryption(), introduced by commit<br /> 859054147318 ("net: tls: handle backlogging of crypto requests"), has<br /> a use-after-free due to double cleanup of encrypt_pending and the<br /> scatterlist entry.<br /> <br /> When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to<br /> the cryptd backlog and the async callback tls_encrypt_done() will be<br /> invoked upon completion. That callback unconditionally restores the<br /> scatterlist entry (sge-&gt;offset, sge-&gt;length) and decrements<br /> ctx-&gt;encrypt_pending. However, if tls_encrypt_async_wait() returns an<br /> error, the synchronous error path in tls_do_encryption() performs the<br /> same cleanup again, double-decrementing encrypt_pending and<br /> double-restoring the scatterlist.<br /> <br /> The double-decrement corrupts the encrypt_pending sentinel (initialized<br /> to 1), making tls_encrypt_async_wait() permanently skip the wait for<br /> pending async callbacks. A subsequent sendmsg can then free the<br /> tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still<br /> pending, resulting in a use-after-free when the callback fires on the<br /> freed record.<br /> <br /> Fix this by skipping the synchronous cleanup when the -EBUSY async<br /> wait returns an error, since the callback has already handled<br /> encrypt_pending and sge restoration.