Skip to main content
cve.nowby Sazabi
← All vulnerabilities
CVE-2026-31533

net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption

Published
Last modified
published
Not listed in CISA KEV
Fix
Fixed in 5.15.203, 6.1.169, 6.6.135, 6.8, 6.12.82, and 2 more
None on Exploit-DB, Metasploit or GitHub
  • Exploitation: none
  • Automatable: yes
  • Technical impact: total

Summary

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.

Timeline

  1. CVE published
  2. CISA SSVC assessment

    Exploitation: none · Automatable: yes · Technical impact: total

  3. Record last updated

Affected versions

  • Linux Linux

    From 3ade391adc584f17b5570fd205de3ad029090368 · fixed in 414fc5e5a5aff776c150f1b86770e0a25a35df3a; From cd1bbca03f3c1d845ce274c0d0a66de8e5929f72 · fixed in 02f3ecadb23558bbe068e6504118f1b712d4ece0; From 13eca403876bbea3716e82cdfe6f1e6febb38754 · fixed in 0e43e0a3c94044acc74b8e0927c27972eb5a59e8; From 8590541473188741055d27b955db0777569438e3 · fixed in aa9facde6c5005205874c37db3fd25799d741baf; From 8590541473188741055d27b955db0777569438e3 · fixed in 5d70eb25b41e9b010828cd12818b06a0c3b04412; From 8590541473188741055d27b955db0777569438e3 · fixed in 2694d408b0e595024e0fc1d64ff9db0358580f74; From 8590541473188741055d27b955db0777569438e3 · fixed in a9b8b18364fffce4c451e6f6fd218fa4ab646705; From 5.15.160 · fixed in 5.15.203; From 6.1.84 · fixed in 6.1.169; From 6.6.18 · fixed in 6.6.135; From 6.7.6 · fixed in 6.8

  • Linux Linux

    6.8

  • KernelLinux

    fixed in 5.15.203; From 5.16.0 · fixed in 6.1.169; From 6.2.0 · fixed in 6.6.135; From 6.7.0 · fixed in 6.12.82; From 6.8.0 · fixed in 6.18.23; From 6.13.0 · fixed in 6.19.13

References 7

git.kernel.org