CVE-2024-53122: Linux Kernel Race Condition Vulnerability

CVE-2024-53122 Overview

CVE-2024-53122 is a race condition vulnerability in the Linux kernel's Multipath TCP (MPTCP) implementation, specifically within the mptcp_rcv_space_adjust function. The vulnerability occurs when additional active subflows created by the in-kernel path manager are included in the subflow list before the completion of the TCP three-way handshake (3WHS). A racing recvmsg() operation spooling data on an already established subflow can unconditionally call tcp_cleanup_rbuf() on all current subflows, including newly created ones that are not yet in a suitable state, potentially triggering a divide-by-zero error.

Critical Impact

Local attackers with low privileges can exploit this race condition to cause a denial of service through a kernel divide-by-zero error, potentially crashing the system or causing instability in MPTCP-enabled network communications.

Affected Products

• Linux Kernel versions prior to patched releases
• Linux Kernel 6.12-rc1 through 6.12-rc7
• Debian Linux (see Debian LTS Announcement)

Discovery Timeline

• 2024-12-02 - CVE-2024-53122 published to NVD
• 2025-11-03 - Last updated in NVD database

Technical Details for CVE-2024-53122

Vulnerability Analysis

The vulnerability resides in the MPTCP subsystem's receive space adjustment mechanism. MPTCP allows multiple TCP connections (subflows) to be aggregated under a single connection, improving resilience and throughput. The in-kernel path manager is responsible for creating and managing these subflows dynamically.

The core issue is a race condition (CWE-362) between subflow creation and receive buffer processing. When a new subflow is being created, it gets added to the subflow list immediately, but the TCP connection establishment (three-way handshake) has not yet completed. During this window, if another thread calls recvmsg() on the MPTCP socket to receive data from an already established subflow, the function iterates through all subflows and calls tcp_cleanup_rbuf() on each one without checking whether the subflow has completed connection establishment.

For newly created subflows that haven't completed the 3WHS, certain internal state variables may be uninitialized or set to zero. When tcp_cleanup_rbuf() attempts to perform calculations using these values, it can result in a divide-by-zero error, causing a kernel panic or system crash.

Root Cause

The root cause is insufficient state validation before invoking tcp_cleanup_rbuf() on MPTCP subflows. The code failed to verify that each subflow had completed its TCP connection establishment before performing receive buffer cleanup operations. The fix explicitly checks that each subflow is in a suitable state (connection established) before invoking tcp_cleanup_rbuf().

Attack Vector

This is a local attack vector requiring low privileges. An attacker with access to a local user account on a system with MPTCP enabled can craft a scenario that triggers the race condition:

1. The attacker creates an MPTCP socket with multiple subflows enabled
2. During active data transfer on an established subflow, the kernel path manager initiates creation of additional subflows
3. By precisely timing recvmsg() calls during the brief window when new subflows exist in the list but haven't completed the 3WHS, the attacker can trigger the vulnerable code path
4. The divide-by-zero error causes kernel panic or denial of service

The attack does not require any user interaction and can be automated once the timing characteristics of the target system are understood.

Detection Methods for CVE-2024-53122

Indicators of Compromise

• Kernel panic messages referencing divide-by-zero errors in MPTCP-related functions
• System crashes or unexpected reboots on systems with active MPTCP connections
• Kernel log entries (dmesg) showing errors in mptcp_rcv_space_adjust or tcp_cleanup_rbuf
• Repeated MPTCP connection failures or instability during high-concurrency network operations

Detection Strategies

• Monitor kernel logs for divide-by-zero exceptions or MPTCP subsystem errors using syslog or journald
• Implement kernel crash dump analysis to identify MPTCP-related stack traces
• Use eBPF-based tracing tools to monitor MPTCP subflow state transitions and detect anomalous timing patterns
• Deploy runtime kernel integrity monitoring to detect unexpected kernel panics

Monitoring Recommendations

• Enable kernel crash dump collection (kdump) to capture forensic data from any MPTCP-related crashes
• Configure alerting on kernel oops/panic events, particularly those involving network subsystem functions
• Monitor system uptime and unplanned reboot events on servers utilizing MPTCP
• Implement network connection monitoring to track MPTCP subflow creation patterns

How to Mitigate CVE-2024-53122

Immediate Actions Required

• Update the Linux kernel to a patched version that includes the fix for CVE-2024-53122
• If immediate patching is not possible, consider disabling MPTCP temporarily on affected systems
• Review and audit which systems have MPTCP enabled and prioritize patching based on exposure
• Monitor affected systems for signs of exploitation attempts or unexpected crashes

Patch Information

The Linux kernel maintainers have released patches addressing this vulnerability. The fix adds explicit state checking before calling tcp_cleanup_rbuf() to ensure subflows are in a suitable state. Patches are available through the following kernel commits:

• Kernel Commit 24995851d58c
• Kernel Commit aad6412c63ba
• Kernel Commit ce7356ae3594
• Kernel Commit ff825ab2f455

Debian users should refer to the Debian LTS Security Announcement for distribution-specific updates.

Workarounds

• Disable MPTCP at the kernel level if not required for operations: sysctl -w net.mptcp.enabled=0
• Restrict access to systems where MPTCP is required to trusted users only
• Implement network segmentation to limit exposure of MPTCP-enabled systems
• Consider using application-level connection pooling instead of MPTCP where feasible until patching is complete

# Disable MPTCP temporarily as a workaround
sysctl -w net.mptcp.enabled=0

# Make the change persistent across reboots
echo "net.mptcp.enabled=0" >> /etc/sysctl.conf
sysctl -p

# Verify MPTCP is disabled
sysctl net.mptcp.enabled