CVE-2026-31533: Linux Kernel Use-After-Free Vulnerability

CVE-2026-31533 Overview

A use-after-free vulnerability has been identified in the Linux kernel's TLS (Transport Layer Security) implementation within the tls_do_encryption() function. The flaw exists in the -EBUSY error path handling, introduced by commit 859054147318 ("net: tls: handle backlogging of crypto requests"). This vulnerability can lead to memory corruption and potential system instability when processing TLS encryption requests.

Critical Impact

This use-after-free vulnerability in the Linux kernel's net/tls subsystem can lead to memory corruption through double cleanup of encrypt_pending and scatterlist entries, potentially allowing attackers to cause system crashes or exploit the freed memory for malicious purposes.

Affected Products

• Linux kernel versions with TLS encryption support (net/tls subsystem)
• Systems utilizing kernel TLS offload functionality
• Linux distributions running vulnerable kernel versions with commit 859054147318

Discovery Timeline

• 2026-04-23 - CVE-2026-31533 published to NVD
• 2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-31533

Vulnerability Analysis

This vulnerability stems from a race condition in the asynchronous crypto request handling within the TLS encryption path. When crypto_aead_encrypt() returns -EBUSY, the crypto request is enqueued to the cryptd backlog, and the async callback tls_encrypt_done() is invoked upon completion.

The async callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, when tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup operations again. This results in:

1. Double-decrement of encrypt_pending, corrupting the sentinel value (initialized to 1)
2. Double-restoration of the scatterlist entry
3. tls_encrypt_async_wait() permanently skipping the wait for pending async callbacks

The corrupted encrypt_pending sentinel allows a subsequent sendmsg call to free the tls_rec structure via bpf_exec_tx_verdict() while a cryptd callback is still pending. When the callback eventually fires, it operates on freed memory, resulting in a classic use-after-free condition.

Root Cause

The root cause is improper synchronization between the asynchronous crypto callback (tls_encrypt_done()) and the synchronous error handling path in tls_do_encryption(). Both code paths perform cleanup of shared state (encrypt_pending counter and scatterlist metadata) without proper coordination, leading to double-free semantics when the -EBUSY async wait returns an error.

Attack Vector

The vulnerability can be triggered through normal TLS socket operations when the crypto subsystem experiences backpressure. An attacker with the ability to create TLS connections and generate encryption load could potentially:

1. Create conditions that cause crypto_aead_encrypt() to return -EBUSY
2. Trigger the error path in tls_encrypt_async_wait()
3. Corrupt the encrypt_pending sentinel through double-decrement
4. Issue subsequent sendmsg calls to free the tls_rec while callbacks are pending
5. Exploit the use-after-free when the delayed crypto callback accesses freed memory

The exploitation requires local access or network-based interaction with a vulnerable TLS-enabled service. The attack complexity depends on the ability to reliably trigger crypto backlog conditions.

Detection Methods for CVE-2026-31533

Indicators of Compromise

• Kernel panic or oops messages referencing tls_encrypt_done or tls_do_encryption functions
• Memory corruption indicators in kernel logs related to the net/tls subsystem
• Unexpected system crashes during high TLS encryption workloads
• KASAN (Kernel Address Sanitizer) reports indicating use-after-free in TLS encryption paths

Detection Strategies

• Monitor kernel logs for warnings or errors from the net/tls module during TLS operations
• Deploy kernel debugging tools like KASAN to detect memory safety violations in production-like environments
• Implement system monitoring for unexpected TLS socket failures or crashes
• Review audit logs for anomalous patterns of TLS connection failures

Monitoring Recommendations

• Enable kernel crash dump analysis to capture evidence of exploitation attempts
• Configure alerting on kernel oops or panic events related to networking subsystems
• Monitor system stability metrics for signs of memory corruption
• Track TLS encryption throughput for unusual patterns that might indicate exploitation attempts

How to Mitigate CVE-2026-31533

Immediate Actions Required

• Update to a patched Linux kernel version that includes the fix for this vulnerability
• Review systems running TLS offload or kernel TLS to prioritize patching
• Consider temporarily disabling kernel TLS if patches cannot be immediately applied
• Monitor systems for signs of exploitation during the patching window

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability. The fix skips the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration. Multiple commits have been released across kernel stable branches:

• Kernel Git Commit 02f3eca
• Kernel Git Commit 0e43e0a
• Kernel Git Commit 2694d40
• Kernel Git Commit 414fc5e
• Kernel Git Commit 5d70eb2
• Kernel Git Commit a9b8b18
• Kernel Git Commit aa9facd

Workarounds

• Disable kernel TLS offload by using userspace TLS implementations instead (e.g., OpenSSL in userspace mode)
• Restrict access to TLS socket creation to trusted users and processes
• Implement network segmentation to limit exposure of vulnerable systems
• Consider using application-level encryption as an alternative to kernel TLS

# Check current kernel version
uname -r

# Verify if kernel TLS is in use
lsmod | grep tls

# Temporarily disable kernel TLS module if not critical
modprobe -r tls