CVE-2026-31533: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption
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.
Security readout for executives and security teams
Plain-English summary
A flaw in Linux kernel TLS encryption cleanup can leave an asynchronous cryptographic operation referencing memory that has already been freed. A triggered failure could crash or corrupt the kernel and, under the supplied CVSS assessment, potentially compromise confidentiality, integrity, and availability. The evidence does not establish real-world exploitation.
Executive priority
Treat as an urgent kernel remediation item where affected kernel TLS functionality is used, particularly on externally reachable or high-value systems. Do not assume every Linux host is equally exposed. Establish usage and vendor patch status promptly, then schedule updates according to confirmed exposure and operational risk.
Technical view
When crypto_aead_encrypt() returns -EBUSY and the asynchronous wait fails, both the callback and synchronous error path clean up encrypt_pending and the scatterlist. This corrupts pending-operation tracking. A later sendmsg can free tls_rec through bpf_exec_tx_verdict() before a cryptd callback finishes, causing a use-after-free. The fix prevents duplicate synchronous cleanup on this path.
Likely exposure
Exposure is limited to Linux systems running an affected kernel where kernel TLS transmission reaches the asynchronous crypto backlog and associated error path. The supplied affected-version data is unusual and includes commit identifiers alongside releases, so organizations should verify exact distribution kernels and backports with their vendors rather than relying solely on version strings.
Exploitation context
The supplied record assigns CVSS 9.8 with network reachability, low complexity, no privileges, and no user interaction. However, it provides no proof of concept, observed attacks, or confirmation of practical remote exploitation. The CVE is not identified as being in CISA KEV, and the precise triggering prerequisites remain incompletely documented here.
Researcher notes
The defect is a callback-lifetime and accounting failure, not merely an isolated double decrement. The corrupted sentinel allows future operations to bypass waiting, creating the record lifetime violation. The source bundle names the repaired behavior but does not establish reliable exploitability, affected distribution mappings, required BPF configuration, or whether code execution is achievable rather than a crash.
Mitigation direction
Apply a vendor-supported kernel update containing the referenced upstream fix.
Check distribution and appliance advisories for backported fixes and exact affected builds.
Prioritize internet-facing or sensitive systems using Linux kernel TLS.
If immediate updating is impossible, consult vendor guidance about safely reducing kernel TLS exposure.
Validation and detection
Inventory running kernel builds and compare them with vendor advisories and fix commits.
Determine whether kernel TLS transmission is enabled or used by deployed workloads.
Verify installed kernel packages contain the applicable upstream or vendor backport.
After updating, confirm systems booted into the remediated kernel build.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-31533 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
10Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.