CVE-2026-31533

What it actually does

This is a Linux kernel use-after-free in the kernel TLS transmit path. When asynchronous AEAD encryption is backlogged and returns -EBUSY, both the asynchronous completion callback and a synchronous error path can clean up the same state, corrupting the encrypt_pending counter and scatterlist metadata. That corruption can cause later TLS send operations to free a TLS record while a cryptographic callback still references it. When the callback runs, it may access freed kernel memory, potentially leading to kernel memory corruption, denial of service, information disclosure, or code execution in kernel context depending on allocator state, hardening, and exploitability on the target kernel build.

Why it matters to the business

Affected Linux systems that use kernel TLS may be exposed to remotely triggerable kernel crashes or, in the worst case, full host compromise. The highest operational risk is service disruption from kernel panic or networking instability on servers handling TLS traffic through affected kernel paths. Although the EPSS score is currently low, the CVSS rating is critical because successful exploitation could affect confidentiality, integrity, and availability at the operating-system level. There is no current CISA KEV listing and no known ransomware use reported in the provided data, but the vulnerability has been public for 111 days, so organizations should prioritize kernel updates on internet-facing or high-throughput TLS systems.

How an attack unfolds

An attacker targets a Linux system or service that exercises the kernel TLS transmit path. By causing TLS data to be sent under conditions where the kernel crypto request is backlogged and crypto_aead_encrypt() returns -EBUSY, the attacker can drive the vulnerable error-handling path in tls_do_encryption(). If tls_encrypt_async_wait() returns an error, the kernel may perform cleanup that the asynchronous tls_encrypt_done() callback also performs. This double cleanup corrupts the pending-encryption state, allowing a later sendmsg path to free a TLS record while a cryptographic callback is still pending. When the callback eventually executes, it dereferences the freed record. Practical exploitation would likely require precise timing, repeated triggering, knowledge of the target kernel configuration, and heap-shaping techniques; the most likely observable outcome is a kernel oops, panic, or networking service disruption, while advanced exploitation could attempt kernel memory corruption for privilege escalation or remote code execution.

How to fix it

Upgrade affected Linux kernels to a vendor-supported release that includes the upstream fix for the net/tls tls_do_encryption() -EBUSY error-path use-after-free. Because no exact fixed versions were provided, use distribution advisories and kernel package changelogs to identify the first fixed kernel for each platform. Prioritize externally reachable servers, TLS-heavy workloads, systems using kTLS, and hosts with BPF/sockmap or TLS offload features enabled. If immediate patching is not possible, reduce exposure by disabling or avoiding kernel TLS where feasible, moving workloads to user-space TLS implementations, disabling optional TLS offload features that exercise kTLS paths, and limiting network access to affected services. Reboot into the fixed kernel after updating; merely installing the package is insufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version, not only the installed package version, and checking that it maps to a vendor advisory or kernel build containing the net/tls fix. Review kernel changelogs for references to fixing a use-after-free in tls_do_encryption(), -EBUSY handling, encrypt_pending cleanup, or tls_encrypt_done(). Validate whether kTLS is available or active by checking kernel configuration, loaded modules, and application/runtime settings that enable kernel TLS. For exposure assessment, identify hosts running affected kernels that provide TLS services and determine whether traffic can traverse the kernel TLS path. After patching and rebooting, monitor kernel logs during TLS load tests for absence of KASAN use-after-free reports, kernel oops messages, panics, or stack traces involving tls_do_encryption(), tls_encrypt_done(), crypto_aead_encrypt(), cryptd, sendmsg, or bpf_exec_tx_verdict().

Typical attack path

1. Identify a reachable service or workload that uses Linux kernel TLS functionality on an affected kernel.
2. Establish or interact with TLS connections that cause data to be transmitted through the kernel TLS send path.
3. Create conditions that backlog asynchronous kernel crypto operations so crypto_aead_encrypt() returns -EBUSY.
4. Trigger the tls_do_encryption() error path where synchronous cleanup races or overlaps with asynchronous callback cleanup.
5. Cause a subsequent sendmsg path to release the TLS record while the cryptographic completion callback is still pending.
6. Wait for the pending callback to execute and access freed kernel memory, causing a crash or enabling further memory-corruption exploitation.

How to detect it

Look for evidence of attempted or successful triggering in kernel and system logs rather than application logs alone. Relevant sources include dmesg, journalctl kernel logs, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, KASAN/KFENCE reports, and EDR telemetry that captures kernel panics or oops traces. Search for stack traces referencing the Linux kernel TLS transmit path, asynchronous crypto backlog handling, and cryptd callbacks, especially tls_do_encryption(), tls_encrypt_done(), crypto_aead_encrypt(), tls_encrypt_async_wait(), bpf_exec_tx_verdict(), sendmsg, and use-after-free reports. Signs of exploitation may include repeated kernel oopses or panics during TLS traffic, networking service resets followed by host reboot, slab allocator corruption, KASAN reports involving freed tls_rec-like objects, or crashes on cryptd worker threads. Because generic network indicators are not reliable for this flaw, correlate crashes with bursts of TLS connections or high-volume TLS writes from common source IPs shortly before the event. No named threat actors or active exploitation campaigns were provided, and there are no stable packet-level IOCs known from the supplied data.

• tls_do_encryption
• tls_encrypt_done
• tls_encrypt_async_wait
• crypto_aead_encrypt
• bpf_exec_tx_verdict
• cryptd
• net/tls
• use-after-free
• BUG: KASAN: use-after-free
• KASAN: use-after-free in tls_encrypt_done
• kernel BUG at net/tls
• Oops:
• general protection fault
• slab-use-after-free
• kernel panic
• sendmsg

What your security team should do

• Patch and reboot internet-facing or TLS-heavy Linux systems first, especially systems using kTLS, TLS offload, BPF sockmap, or high-volume encrypted networking.
• Use distribution security advisories to map affected kernel packages to fixed releases, since exact fixed versions were not provided in the input.
• Inventory systems where kernel TLS is enabled or likely used, and treat those as higher priority than systems relying exclusively on user-space TLS.
• If patching is delayed, disable or avoid kTLS and optional TLS offload paths where operationally feasible.
• Increase monitoring for kernel oops, panic, KASAN, and networking stack crash signatures involving net/tls and cryptd callback paths.
• Run post-remediation validation to ensure hosts are booted into the fixed kernel, not merely staged for update.
• Track threat intelligence and vendor advisories for any change in exploit maturity, KEV status, or public proof-of-concept availability.