Skip to main content

CVE-2024-45009: Vulnerability in Linux Linux

Medium
VulnerabilityCVE-2024-45009cvecve-2024-45009
Published: Wed Sep 11 2024 (09/11/2024, 15:13:47 UTC)
Source: CVE
Vendor/Project: Linux
Product: Linux

Description

In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: only decrement add_addr_accepted for MPJ req Adding the following warning ... WARN_ON_ONCE(msk->pm.add_addr_accepted == 0) ... before decrementing the add_addr_accepted counter helped to find a bug when running the "remove single subflow" subtest from the mptcp_join.sh selftest. Removing a 'subflow' endpoint will first trigger a RM_ADDR, then the subflow closure. Before this patch, and upon the reception of the RM_ADDR, the other peer will then try to decrement this add_addr_accepted. That's not correct because the attached subflows have not been created upon the reception of an ADD_ADDR. A way to solve that is to decrement the counter only if the attached subflow was an MP_JOIN to a remote id that was not 0, and initiated by the host receiving the RM_ADDR.

AI-Powered Analysis

AILast updated: 06/28/2025, 23:42:11 UTC

Technical Analysis

CVE-2024-45009 is a vulnerability identified in the Linux kernel's implementation of Multipath TCP (MPTCP), specifically within the path manager (pm) component that handles subflow management. MPTCP allows a single TCP connection to use multiple paths to maximize resource usage and increase redundancy. The vulnerability arises from incorrect decrementing of the add_addr_accepted counter during the removal of subflows. In the MPTCP protocol, when a subflow endpoint is removed, a RM_ADDR (remove address) notification is sent, followed by subflow closure. Prior to the patch, upon receiving RM_ADDR, the peer would decrement the add_addr_accepted counter regardless of whether the subflow was created from an ADD_ADDR notification or not. This behavior is incorrect because some subflows, particularly those initiated by MP_JOIN requests with a remote ID not equal to zero, do not correspond to an ADD_ADDR event and thus should not cause the counter to decrement. The flaw was detected by adding a warning (WARN_ON_ONCE) that triggers if the counter reaches zero unexpectedly during the "remove single subflow" subtest in the mptcp_join.sh selftest. The fix involves decrementing the add_addr_accepted counter only if the subflow was initiated by an MP_JOIN to a remote ID other than zero and initiated by the host receiving the RM_ADDR. This correction prevents the counter from being decremented erroneously, which could otherwise lead to inconsistent internal state management within the MPTCP path manager. Although no known exploits are currently reported in the wild, the vulnerability affects Linux kernel versions identified by the commit hash d0876b2284cf8b34dd214b2d0aa21071c345da59 and potentially other versions containing the flawed logic. The vulnerability is subtle and relates to internal protocol state management rather than direct memory corruption or privilege escalation, but it could potentially cause unexpected behavior or denial of service in systems relying on MPTCP for network resilience and performance.

Potential Impact

For European organizations, the impact of CVE-2024-45009 depends largely on their reliance on Linux systems utilizing MPTCP, which is commonly employed in environments requiring high availability and network redundancy, such as telecommunications, cloud infrastructure, and critical enterprise networks. Incorrect handling of subflow removal could lead to inconsistent MPTCP state, potentially causing connection instability or denial of service in multi-path TCP sessions. This could degrade network performance, disrupt critical communications, or impact services that depend on seamless failover and load balancing across multiple network interfaces. While the vulnerability does not appear to allow direct code execution or privilege escalation, the disruption of network connectivity could affect business continuity, especially in sectors like finance, healthcare, and public services where Linux-based infrastructure is prevalent. Additionally, organizations deploying MPTCP in IoT or industrial control systems might experience operational interruptions. Given the lack of known exploits, the immediate risk is moderate; however, the subtle nature of the bug means it could be exploited in targeted attacks or cause hard-to-diagnose network issues if left unpatched.

Mitigation Recommendations

To mitigate CVE-2024-45009, European organizations should: 1) Apply the official Linux kernel patches that address this vulnerability as soon as they become available from trusted sources or Linux distributions. 2) For environments where immediate patching is not feasible, consider disabling MPTCP if it is not essential, to eliminate exposure. 3) Monitor network performance and logs for anomalies related to MPTCP subflow management, such as unexpected connection drops or warnings similar to WARN_ON_ONCE triggers. 4) Conduct thorough testing of MPTCP functionality post-patching to ensure stability and correct behavior of multi-path TCP connections. 5) Engage with Linux distribution vendors and security advisories to stay informed about updates and backported fixes. 6) For critical infrastructure, implement network segmentation and redundancy strategies that do not solely rely on MPTCP to minimize impact from potential MPTCP-related issues. 7) Educate network and system administrators about this vulnerability to recognize symptoms and respond promptly.

Need more detailed analysis?Get Pro

Technical Details

Data Version
5.1
Assigner Short Name
Linux
Date Reserved
2024-08-21T05:34:56.679Z
Cisa Enriched
true
Cvss Version
null
State
PUBLISHED

Threat ID: 682d9826c4522896dcbe0e9c

Added to database: 5/21/2025, 9:08:54 AM

Last enriched: 6/28/2025, 11:42:11 PM

Last updated: 8/3/2025, 12:44:08 AM

Views: 14

Actions

PRO

Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.

Please log in to the Console to use AI analysis features.

Need enhanced features?

Contact root@offseq.com for Pro access with improved analysis and higher rate limits.

Latest Threats