CVE-2026-31533

Advisory lineage Upstream: 0 Downstream: 83
Analyzed
Published: 23 Apr 2026, 15:11
Last modified:14 Jul 2026, 12:48

Vulnerability Summary

Overall Risk (default)
high
70/100
CVSS Score
9.8 CRITICAL
v3.1 (cve.org)
EPSS Score
0.26% LOW
0% probability 0.00%
KEV
Not listed
Ransomware
No reports
Public exploits
None found
Dark Web
Not detected

Timeline

23 Apr 2026, 15:11
Published
Vulnerability first disclosed
14 Jul 2026, 12:48
Last Modified
Vulnerability information updated

Description

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.

CVSS Metrics

  • v3.1•CRITICAL•Score: 9.8CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

EPSS Trends

Current EPSS score: 0.26%• Percentile: 18%

Techniques & Countermeasures

  • CWE-416•Use After Free

    The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.

Affected Systems

  • linux•linux

    ≥ 3ade391adc584f17b5570fd205de3ad029090368, < 414fc5e5a5aff776c150f1b86770e0a25a35df3a | ≥ cd1bbca03f3c1d845ce274c0d0a66de8e5929f72, < 02f3ecadb23558bbe068e6504118f1b712d4ece0 | ≥ 13eca403876bbea3716e82cdfe6f1e6febb38754, < 0e43e0a3c94044acc74b8e0927c27972eb5a59e8 | ≥ 8590541473188741055d27b955db0777569438e3, < aa9facde6c5005205874c37db3fd25799d741baf | ≥ 8590541473188741055d27b955db0777569438e3, < 5d70eb25b41e9b010828cd12818b06a0c3b04412 | ≥ 8590541473188741055d27b955db0777569438e3, < 2694d408b0e595024e0fc1d64ff9db0358580f74 | ≥ 8590541473188741055d27b955db0777569438e3, < a9b8b18364fffce4c451e6f6fd218fa4ab646705 | ab6397f072e5097f267abf5cb08a8004e6b17694 | ≥ 5.15.160, < 5.15.203 | ≥ 6.1.84, < 6.1.169 | ≥ 6.6.18, < 6.6.135 | ≥ 6.7.6, < 6.8 | 6.8

  • linux•linux kernel

    ≥ 5.15.160, < 5.15.203 | ≥ 6.1.84, < 6.1.169 | ≥ 6.6.18, < 6.6.135 | ≥ 6.7.6, < 6.8 | ≥ 6.8.1, < 6.12.82 | ≥ 6.13, < 6.18.23 | ≥ 6.19, < 6.19.13 | 7.0:rc1 | 7.0:rc2 | 7.0:rc3 | 7.0:rc4 | 7.0:rc5 | 7.0:rc6 | 7.0:rc7

References (9)