CVE-2024-26583: Linux Kernel Race Condition Vulnerability

CVE-2024-26583 Overview

CVE-2024-26583 is a race condition vulnerability in the Linux kernel's Transport Layer Security (TLS) subsystem. The flaw exists in the async notification path where the submitting thread that called recvmsg or sendmsg may exit immediately after the async crypto handler invokes complete(). Any code executed after that point risks touching already freed data, leading to use-after-free conditions. The vulnerability affects local attackers with low privileges and can trigger kernel memory corruption resulting in system instability or denial of service. The issue is tracked under CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization).

Critical Impact

Local low-privileged attackers can trigger a race condition in the kernel TLS layer, leading to use-after-free conditions and potential denial of service through kernel memory corruption.

Affected Products

• Linux Kernel (multiple stable branches prior to the patched commits)
• Distributions shipping vulnerable kernel builds, including Fedora
• Systems using kernel TLS (kTLS) with async crypto offload

Discovery Timeline

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

Technical Details for CVE-2024-26583

Vulnerability Analysis

The vulnerability resides in the Linux kernel TLS implementation (net/tls) where asynchronous cryptographic operations interact with socket lifecycle management. When a user-space process calls recvmsg() or sendmsg() on a kTLS socket configured with async crypto, the submitting thread may return to user space and exit as soon as the async crypto handler signals completion via complete(). Any kernel code path that continues to access submission-thread state after this signal can dereference memory that has been released. This is a classic time-of-check to time-of-use pattern affecting kernel data structures shared between the submitter and the async completion handler.

Root Cause

The root cause is improper synchronization between the thread submitting TLS work and the async crypto completion callback. The original implementation relied on locking and reinit flags to coordinate the two paths, but it left a window where the submitting thread could exit before the completion handler finished touching shared state. The fix replaces the fragile locking pattern with an atomic reference count. The main thread holds an extra reference for the duration of the operation, ensuring the shared structure remains valid until both the submitter and the async handler release their references. The patch also removes the unsafe reinitialization of the completion object.

Attack Vector

Exploitation requires local access and the ability to open and operate a kTLS socket using async crypto offload. A local attacker schedules concurrent TLS operations and forces the submitting thread to exit during the async completion window. Successful exploitation produces a use-after-free in kernel memory, which manifests as a kernel panic or hang affecting system availability. The attack complexity is high because the attacker must reliably win the narrow race window between complete() and the trailing code in the submitter path. No code execution, confidentiality, or integrity impact is reported for this issue.

Detection Methods for CVE-2024-26583

Indicators of Compromise

• Kernel oops or panic messages referencing tls_sw, tls_decrypt_done, or async crypto completion paths in dmesg or /var/log/messages
• KASAN (Kernel Address Sanitizer) reports of use-after-free in the net/tls subsystem on instrumented kernels
• Unexplained socket-related kernel crashes on hosts running services that negotiate kTLS with hardware or async software crypto

Detection Strategies

• Inventory kernel versions across Linux hosts and compare against the patched commits listed in the upstream stable tree
• Monitor crash reporting pipelines (kdump, abrt, systemd-coredump) for kernel faults originating in TLS code paths
• Enable kernel auditing for processes opening sockets with TCP_ULP set to tls to identify workloads that exercise the affected code

Monitoring Recommendations

• Centralize kernel log collection and alert on repeated faults in tls_sw.c or async crypto callbacks
• Track package and kernel update status across the fleet to confirm patched builds are deployed
• Correlate kernel instability events with workloads using TLS offload, such as nginx with kTLS or storage protocols over TLS

How to Mitigate CVE-2024-26583

Immediate Actions Required

• Update the Linux kernel to a version containing the upstream fixes referenced by commits aec7961916f3, 7a3ca06d04d5, 86dc27ee36f5, and 6209319b2efd
• Apply distribution updates such as the Fedora package announcement covering this CVE
• Reboot affected systems after kernel upgrade so the patched image is loaded

Patch Information

The fix is available in the mainline Linux kernel and backported across multiple stable branches. Refer to the upstream commits: Linux Kernel Commit aec7961, Linux Kernel Commit 6209319, Linux Kernel Commit 7a3ca06, Linux Kernel Commit 86dc27e, and Linux Kernel Commit f17d21e. Distribution users should consult the Fedora Package Announcement for packaged builds.

Workarounds

• Disable kTLS offload on workloads that do not require it by removing the TCP_ULPtls configuration from application sockets
• Restrict local user access on multi-tenant systems to limit who can open arbitrary TLS sockets and exercise async crypto paths
• Avoid loading the tls kernel module on hosts that do not use kernel TLS until a patched kernel is deployed

# Verify the running kernel and confirm patched build is installed
uname -r

# Check whether the tls module is loaded
lsmod | grep '^tls'

# Unload the tls module on hosts that do not require kTLS
sudo modprobe -r tls

# Apply distribution updates (Fedora example)
sudo dnf update kernel kernel-core
sudo systemctl reboot