CVE-2024-26800

What it actually does

Use-after-free in Linux kernel TLS decryption: when crypto_aead_decrypt returns -EBUSY, tls_do_decryption waits but tls_decrypt_sg still releases pages that tls_decrypt_done already freed via the async callback.

Why it matters to the business

Kernel crashes, memory corruption, or potential remote code execution on Linux systems handling TLS traffic, causing service outages and possible compromise of network-facing workloads.

How an attack unfolds

An attacker sends specially crafted TLS records that force the decryption request onto the backlog path returning -EBUSY; the resulting double-free of socket buffer pages can be leveraged to corrupt kernel memory and achieve code execution.

How to fix it

Apply the upstream fix in commit df0cc57e057f18e44dac8e6c18aba47ab53202f9 or later; rebuild and deploy the patched kernel across all affected systems.

How to confirm the fix worked

Verify the running kernel contains commit df0cc57e057f18e44dac8e6c18aba47ab53202f9 or a backported equivalent; test TLS decryption workloads for stability under backlog conditions.

Typical attack path

1. Establish TLS connection to target
2. Send malicious record that triggers async backlog decryption returning -EBUSY
3. Trigger double-free of pages in tls_decrypt_sg and tls_decrypt_done
4. Exploit resulting use-after-free for kernel memory corruption or RCE

How to detect it

Inspect kernel logs for oops/panic messages referencing tls_decrypt_sg, tls_decrypt_done, or -EBADMSG during TLS receive paths; correlate with high-volume TLS connections.

What your security team should do

• Immediately upgrade all Linux kernels to a version containing df0cc57e057f18e44dac8e6c18aba47ab53202f9
• Prioritize patching on systems exposing TLS offload or high-volume encrypted traffic
• Monitor kernel logs for use-after-free oops in tls_decrypt paths until patched