CVE-2024-26584 - Handling Crypto Request Backlogging in the Linux Kernel’s TLS Implementation

In early 2024, a subtle yet important vulnerability was addressed in the Linux kernel’s handling of TLS (Transport Layer Security) cryptographic requests. Known as CVE-2024-26584, this bug had implications for the way crypto operations queued up, especially under system stress or configured limits. Let’s break down what happened, how it was fixed, and why it matters—with clear example code and links to get you started.

TL;DR

- Vulnerability: Linux’s TLS subsystem didn’t properly handle backlogged cryptographic requests, possibly leading to double callback invocations and undefined error handling.
- Impact: Could potentially cause kernel confusion, bad state handling, or even resource leaks under certain loads.

References:

- Original Patch Discussion
- Linux CVE Entry
- Linux Kernel Commit

What’s Going On?

In modern Linux, network (net) code for TLS offloads cryptographic processing—such as encryption and decryption—to the crypto API. When a lot of encryption/decryption requests come in, the system uses a queue (backlog). Sometimes, like when the cryptd queue for AESNI (AES-NI instructions hardware support) fills up, new requests can’t be immediately processed.

The requests are marked with a CRYPTO_TFM_REQ_MAY_BACKLOG flag, letting the API know: “Feel free to enqueue this if you’re busy.”

The API might return -EBUSY (means “Too busy, but I’ll do it later”).

Unfortunately, TLS wasn’t handling -EBUSY properly, because it didn’t expect it. This could lead to improper state tracking and sometimes, confusing double-callbacks like:

Callback with actual result, e.g. err == (should process this)

If the code isn’t prepared, things might go off the rails.

Suppose your system’s CPU cryptd queue is purposefully set to a low length—maybe for testing

# In sysfs (requires root)
echo 2 > /sys/module/cryptd/parameters/cryptd_max_cpu_qlen

Some return -EBUSY, but they’ll still run after a short wait.

If your kernel TLS driver sees -EBUSY and treats it as a hard error, it could fail requests that should have just waited. Oops.

_Old code (bad):_

ret = crypto_aead_encrypt(...);
if (ret == -EINPROGRESS) {
    // Wait for completion...
} else if (ret) {
    // Bail out on error
    return ret;
}

_New code (good):_

ret = crypto_aead_encrypt(...);
if (ret == -EINPROGRESS || ret == -EBUSY) {
    // Both mean: operation is backlogged, will complete async
    tls_crypt_async_wait(...); // Helper from patch
} else if (ret) {
    // Some other failure
    return ret;
}

The actual patch converts -EBUSY to -EINPROGRESS so all the rest of the async and error handling can stay the same, making it easier to maintain and less error-prone.

Exploitability

Is this CVE remotely exploitable?
Not likely in the classic sense—there’s no direct privilege escalation or buffer overflow. But, a skilled attacker could try to trigger resource exhaustion or weird kernel states by flooding with TLS requests, causing a denial of service (DoS) or instability if the kernel isn’t patched.

Here’s a high-level example

# Pseudocode - simulate flooding TLS sockets via Python
import socket, ssl
ctx = ssl.create_default_context()
socks = []
for _ in range(10000):
    s = socket.create_connection(('your-server', 443))
    ssl_sock = ctx.wrap_socket(s)
    socks.append(ssl_sock)

Run this while you have a low cryptd queue, and vulnerable kernels could mishandle the backlog, potentially leaking resources, failing connections, or, in rare cases, panicking.

How the Fix Works

Instead of patching every piece of error-handling logic (which could introduce subtle bugs), the fix centralizes return code handling. With new tls_*crypt_async_wait() helpers:

Recommendations

Are you affected?

If you run custom kernels, distros, or handle lots of TLS traffic, check your kernel version

- Fixed in mainline as of this commit (6.8+)

Backports to major distros landing soon—watch your vendor advisories.

Upgrade Recommendation:
Patch your kernel, or grab a distro update as soon as it’s available.

Mitigation:
If you can’t upgrade now, try to avoid very low cryptd queue limits (the default is safe), and monitor for failed TLS handshakes under load.

Conclusion

CVE-2024-26584 is a great example of how even small mismatches between subsystems—crypto and network—can cause race conditions and subtle bugs. The fix is elegant: treat “backlog” status codes consistently, keeping everything simple and safe.

If you’re a sysadmin or kernel developer, keep your eyes peeled for small details—they matter for long-term stability!

*Original research and explanation by ChatGPT, based on kernel mailing lists and published patches. For questions or corrections, see the references above.*

Timeline

Published on: 02/21/2024 15:15:09 UTC
Last modified on: 04/30/2024 19:35:07 UTC