CVE-2024-26585: Linux Kernel Race Condition Vulnerability

CVE-2024-26585 Overview

CVE-2024-26585 is a race condition vulnerability in the Linux kernel's TLS (Transport Layer Security) implementation. The vulnerability exists in the handling of asynchronous cryptographic operations where improper ordering of work scheduling and completion signaling can lead to a use-after-free or memory corruption scenario when a socket is closed while transmission work is being scheduled.

The vulnerability affects the kernel's TLS subsystem, specifically in the code path handling asynchronous crypto operations during recvmsg() and sendmsg() system calls. When the submitting thread exits immediately after the async crypto handler calls complete(), the race can result in accessing freed memory or corrupted state.

Critical Impact

Local attackers with low privileges can exploit this race condition to cause a denial of service through kernel crashes, potentially affecting system availability on servers and workstations running vulnerable Linux kernel versions.

Affected Products

• Linux Kernel (multiple affected versions)
• linux linux_kernel

Discovery Timeline

• February 21, 2024 - CVE-2024-26585 published to NVD
• November 4, 2025 - Last updated in NVD database

Technical Details for CVE-2024-26585

Vulnerability Analysis

This vulnerability is classified as CWE-362 (Race Condition). The flaw exists in the TLS transmission work scheduling mechanism within the Linux kernel. The core issue involves a timing-sensitive operation where the order of scheduling work and signaling completion to the submitting thread was incorrect.

In the vulnerable code path, when an application calls recvmsg() or sendmsg() on a TLS socket using asynchronous cryptographic operations, the async crypto handler would call complete() before the work was scheduled. This created a window where the submitting thread could exit and release resources while the work scheduling was still in progress.

The fix reorders the operations so that work scheduling occurs before calling complete(). This is the inverse order of what the submitting thread will do, ensuring proper synchronization and preventing the race condition.

Root Cause

The root cause is improper synchronization between the asynchronous cryptographic handler's completion signal and the work scheduling mechanism in the TLS transmit path. The original code called complete() before scheduling the work, which violated the expected ordering and created a race window where the submitting thread could exit prematurely, leaving dangling references or corrupted state.

Attack Vector

Exploitation requires local access to the system. An attacker would need to:

1. Establish a TLS connection using the kernel's TLS implementation (kTLS)
2. Trigger asynchronous cryptographic operations through sendmsg() or recvmsg() calls
3. Exploit the timing window between the completion signal and work scheduling by rapidly opening and closing sockets while performing TLS operations

The attack complexity is high due to the timing-sensitive nature of race conditions. While this vulnerability does not directly lead to code execution, successful exploitation can cause kernel panics or system instability, resulting in denial of service.

The vulnerability mechanism operates as follows: when using kernel TLS with asynchronous crypto operations, the async handler's complete() call signals the submitting thread that it can proceed. If this signal occurs before the work is properly scheduled, the submitting thread may exit and deallocate resources while the kernel still holds references to them. The fix ensures work is scheduled before signaling completion, maintaining proper resource lifecycle management.

Detection Methods for CVE-2024-26585

Indicators of Compromise

• Unexpected kernel panics or system crashes during high-volume TLS operations
• Kernel oops messages referencing TLS subsystem functions or crypto handlers
• System instability when applications use kernel TLS (kTLS) with asynchronous operations
• Crash dumps showing use-after-free patterns in TLS-related kernel memory

Detection Strategies

• Monitor system logs for kernel warnings or errors related to TLS operations using dmesg or journalctl
• Implement kernel crash monitoring to detect patterns consistent with race condition exploitation
• Use kernel debugging tools like KASAN (Kernel Address Sanitizer) to detect memory corruption in development environments
• Deploy endpoint detection solutions capable of identifying anomalous kernel behavior

Monitoring Recommendations

• Enable kernel auditing for socket operations, particularly those involving TLS
• Monitor for unusual patterns of rapid socket creation and destruction
• Configure alerting for kernel oops or panic events with TLS-related stack traces
• Review application logs for unexpected TLS connection failures or resets

How to Mitigate CVE-2024-26585

Immediate Actions Required

• Update the Linux kernel to a patched version that includes the fix for CVE-2024-26585
• If immediate patching is not possible, consider disabling kernel TLS (kTLS) and using userspace TLS implementations
• Monitor affected systems for signs of exploitation or system instability
• Prioritize patching on systems that heavily utilize kTLS for encrypted communications

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability. The fix reorders the work scheduling to occur before calling complete(), ensuring proper synchronization between the async crypto handler and the submitting thread.

Patches are available through the following kernel git commits:

• Kernel Git Commit 6db22d6
• Kernel Git Commit e01e393
• Kernel Git Commit e327ed6
• Kernel Git Commit 196f198
• Kernel Git Commit dd32621

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

Workarounds

• Disable kernel TLS by preventing applications from using the TLS_TX and TLS_RX socket options
• Configure applications to use userspace TLS libraries (like OpenSSL) instead of kTLS
• Limit access to the affected systems to trusted users only, as exploitation requires local access
• Consider using network segmentation to isolate affected systems until patching is complete

# Check current kernel version
uname -r

# Verify if kTLS is enabled (module loaded)
lsmod | grep tls

# Temporarily blacklist the TLS module if not required
echo "blacklist tls" >> /etc/modprobe.d/blacklist-tls.conf

# Update kernel on Debian/Ubuntu-based systems
sudo apt update && sudo apt upgrade linux-image-$(uname -r)

# Update kernel on RHEL/CentOS-based systems
sudo yum update kernel

# Reboot to apply kernel updates
sudo reboot