CVE-2026-31533: Linux Kernel

Critical severity, CVSS 9.8. EPSS: 0.7% chance of exploitation in the next 30 days.

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

Affected products

• Linux Linux Kernel: from 5.15.160, before 5.15.203 (fixed in 5.15.203); from 6.1.84, before 6.1.169 (fixed in 6.1.169); from 6.6.18, before 6.6.135 (fixed in 6.6.135); from 6.7.6, before 6.8 (fixed in 6.8); from 6.8.1, before 6.12.82 (fixed in 6.12.82); from 6.13, before 6.18.23 (fixed in 6.18.23); …

Published 2026-04-23. Last modified 2026-07-14.