KernelScan.io

CRITICAL

tls Encryption UAF

CVE-2026-31533

CVSS 9.8 / 10.0 NVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

KernelScan AI9.8CRITICAL

01

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.

02

Engine v0.2.0

Risk summary

Critical use-after-free vulnerability in kernel TLS implementation. When TLS encryption operations experience crypto backlog conditions, a double cleanup bug can corrupt internal state, allowing subsequent network operations to free memory while async crypto callbacks are still pending. This results in use-after-free when the callback executes on freed memory, potentially leading to kernel crashes or privilege escalation.

Affectednet/tls/tls_sw.c

Vulnerability analysis

Root Cause: Double cleanup in TLS encryption error handling path. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to cryptd backlog and an async callback tls_encrypt_done() handles cleanup (decrementing encrypt_pending and restoring scatterlist). However, if tls_encrypt_async_wait() subsequently returns an error, the synchronous error path performs the same cleanup again, causing double-decrement of encrypt_pending and double-restoration of scatterlist entries.

Attack Surface: Network-accessible TLS connections where crypto operations can experience backlog conditions. The vulnerability requires triggering -EBUSY from crypto_aead_encrypt() followed by an error from tls_encrypt_async_wait(), which can occur when cryptd queues are full and subsequent operations fail.

Fix Mechanism: The patch adds a conditional check to skip synchronous cleanup when tls_encrypt_async_wait() returns an error (rc != -EINPROGRESS). Since the async callback has already handled the cleanup, the synchronous path only needs to remove the record from the list and return the error code, avoiding the double cleanup that corrupts the encrypt_pending sentinel.

03

BranchFixed inPatch commit
5.155.15.203414fc5e5a5af
6.16.1.16902f3ecadb235
6.126.12.825d70eb25b41e
6.186.18.232694d408b0e5
6.196.19.13a9b8b18364ff
6.66.6.1350e43e0a3c940
6.86.8aa9facde6c50
mainline7.0