Linux Kernel TLS Memory Leak in Async Decrypt Wait Scores 7.5

Status: UPDATED  |  Advisory ID: CVE-2026-23414

Key Details

Affected Products, Subsystems & Sectors

What to Know

In the Linux kernel, the following vulnerability has been resolved:

tls: Purge async_hold in tls_decrypt_async_wait()

The async_hold queue pins encrypted input skbs while

the AEAD engine references their scatterlist data. Once

tls_decrypt_async_wait() returns, every AEAD operation

has completed and the engine no longer references those

skbs, so they can be freed unconditionally.

A subsequent patch adds batch async decryption to

tls_sw_read_sock(), introducing a new call site that

must drain pending AEAD operations and release held

skbs. Move __skb_queue_purge(&ctx->async_hold) into

tls_decrypt_async_wait() so the purge is centralized

and every caller -- recvmsg's drain path, the -EBUSY

fallback in tls_do_decryption(), and the new read_sock

batch path -- releases held skbs on synchronization

without each site managing the purge independently.

This fixes a leak when tls_strp_msg_hold() fails part-way through,

after having added some cloned skbs to the async_hold

queue. tls_decrypt_sg() will then call tls_decrypt_async_wait() to

process all pending decrypts, and drop back to synchronous mode, but

tls_sw_recvmsg() only flushes the async_hold queue when one record has

been processed in "fully-async" mode, which may not be the case here.

[[email protected]: added leak comment]

What to Do

Monitor Linux's web page for any future patch releases.

References