CVE-2024-26584: Linux Kernel TLS Crypto DoS Vulnerability

CVE-2024-26584 Overview

CVE-2024-26584 is a vulnerability in the Linux kernel's TLS (Transport Layer Security) subsystem related to improper handling of crypto request backlogging. When the CRYPTO_TFM_REQ_MAY_BACKLOG flag is set on requests to the crypto API, the crypto_aead_{encrypt,decrypt} functions can return -EBUSY instead of -EINPROGRESS under valid conditions. This occurs when the cryptd queue for AESNI becomes full, which can be easily triggered with an artificially low cryptd.cryptd_max_cpu_qlen setting. The vulnerability can lead to denial of service conditions on affected systems.

Critical Impact

Local attackers with user-level privileges can trigger denial of service conditions by exploiting improper error handling in the kernel TLS crypto subsystem, potentially disrupting encrypted network communications.

Affected Products

• Linux Kernel (multiple versions)
• Fedora Linux (various releases)
• Linux-based distributions using affected kernel versions

Discovery Timeline

• 2024-02-21 - CVE-2024-26584 published to NVD
• 2025-11-04 - Last updated in NVD database

Technical Details for CVE-2024-26584

Vulnerability Analysis

The vulnerability exists in the Linux kernel's TLS implementation within the networking subsystem (net: tls). The core issue stems from the kernel's handling of asynchronous cryptographic operations when using hardware-accelerated encryption through AESNI (Advanced Encryption Standard New Instructions).

When the kernel TLS subsystem sets the CRYPTO_TFM_REQ_MAY_BACKLOG flag on cryptographic requests, it indicates that requests can be queued if the crypto engine is busy. However, the original implementation did not properly handle the -EBUSY return code that occurs when the cryptd queue is full. In this scenario, requests are enqueued to the backlog and still processed, but the async callback is invoked twice: first with err == -EINPROGRESS (which should be ignored), then with err == 0 indicating completion.

This vulnerability is classified under CWE-755 (Improper Handling of Exceptional Conditions), as the kernel failed to properly handle the backlogging state of cryptographic operations.

Root Cause

The root cause is the incomplete error handling for the -EBUSY return value from crypto_aead_encrypt() and crypto_aead_decrypt() functions. The TLS subsystem's error handling paths were not designed to account for the dual callback invocation pattern that occurs during backlogged request processing. The fix converts the EBUSY return code to EINPROGRESS using the new tls_*crypt_async_wait() helpers, avoiding modifications to all existing error handling paths.

Attack Vector

The attack requires local access to the system. An attacker with low-level user privileges can exploit this vulnerability by manipulating the cryptd queue depth through the cryptd.cryptd_max_cpu_qlen kernel parameter or by generating a high volume of TLS cryptographic operations to fill the queue. When the queue becomes full and backlogging occurs, the improper error handling can lead to system instability or denial of service affecting TLS-encrypted network communications.

The vulnerability can be triggered when:

1. The cryptd queue for AESNI reaches its maximum capacity
2. New TLS encrypt/decrypt requests are submitted
3. The kernel returns -EBUSY which is not properly handled
4. The dual callback invocation pattern causes unexpected behavior

Detection Methods for CVE-2024-26584

Indicators of Compromise

• Unexpected TLS connection failures or timeouts on affected Linux systems
• Kernel log messages indicating crypto subsystem errors with -EBUSY return codes
• System instability during high-volume TLS operations
• Elevated cryptd queue utilization visible through kernel debugging interfaces

Detection Strategies

• Monitor kernel logs (dmesg) for TLS-related error messages mentioning crypto backlog issues
• Implement alerting on abnormal network connection failures related to TLS encryption
• Track system performance metrics for unusual CPU utilization in crypto worker threads
• Deploy kernel-level monitoring to detect attempts to manipulate cryptd.cryptd_max_cpu_qlen

Monitoring Recommendations

• Enable audit logging for kernel parameter modifications affecting the crypto subsystem
• Monitor network connection establishment failures that may indicate TLS processing issues
• Implement SentinelOne endpoint protection to detect suspicious local activity patterns
• Configure alerting for repeated TLS handshake failures that may indicate exploitation attempts

How to Mitigate CVE-2024-26584

Immediate Actions Required

• Update the Linux kernel to a patched version that includes the fix
• Review and apply available kernel patches from the official Linux kernel repositories
• Monitor Fedora security advisories for distribution-specific updates
• Consider temporarily reducing TLS workload on critical systems until patches are applied

Patch Information

The Linux kernel development team has released patches to address this vulnerability. The fix utilizes new tls_*crypt_async_wait() helper functions to properly handle the -EBUSY return code by converting it to -EINPROGRESS, maintaining compatibility with existing error handling paths.

Patches are available through the following kernel commits:

• Kernel Commit 13eca403
• Kernel Commit 8590541473
• Kernel Commit ab6397f072
• Kernel Commit cd1bbca03f

Fedora users should monitor the Fedora Package Announcement for distribution-specific updates.

Workarounds

• Increase the cryptd.cryptd_max_cpu_qlen parameter to reduce the likelihood of queue saturation
• Limit TLS connection rates on heavily loaded systems to prevent queue overflow conditions
• Consider disabling kernel TLS offload (CONFIG_TLS_DEVICE=n) if not strictly required
• Implement network-level rate limiting to reduce crypto workload during high-traffic periods

# Temporary workaround: Increase cryptd queue length
echo 1000 > /sys/module/cryptd/parameters/cryptd_max_cpu_qlen

# Verify current setting
cat /sys/module/cryptd/parameters/cryptd_max_cpu_qlen

# Monitor for crypto backlog issues in kernel logs
dmesg | grep -i "crypto\|tls\|backlog"