CVE-2025-21938 is a concurrency vulnerability in the Linux kernel's Multipath TCP (MPTCP) implementation, specifically within the mptcp_pm_nl_append_new_local_addr function. The flaw arises when multiple connection requests concurrently attempt to create implicit MPTCP endpoints. During this process, more than one caller may enter mptcp_pm_nl_append_new_local_addr because none find the address in the local_addr_list during their call to mptcp_pm_nl_get_local_id. This concurrency leads to a race condition where multiple new_local_addr calls may delete address entries created by previous callers. The deletion operations use synchronize_rcu, which is not permitted in certain contexts where this function is called, such as during packet reception when the caller is in an RCU read critical section with preemption disabled. This improper use causes kernel scheduling while atomic contexts, resulting in kernel BUGs and potential system instability or crashes. The vulnerability is particularly triggered when an endpoint advertises different external and internal addresses, causing multiple subflow SYN packets to arrive in parallel and increasing the likelihood of the race condition during creation of local_addr_list entries. The root cause is the replacement of existing implicit local addresses during concurrent calls. The fix involves skipping the replacement of an existing implicit local address when called via mptcp_pm_nl_get_local_id, preventing the race and improper synchronize_rcu usage. This vulnerability affects Linux kernel versions identified by the given commit hashes and is relevant to systems using MPTCP, a protocol extension that allows a single TCP connection to use multiple paths for redundancy and performance. No known exploits are reported in the wild as of publication, and no CVSS score has been assigned yet.

For European organizations, this vulnerability poses a risk primarily to servers and network infrastructure running Linux kernels with MPTCP enabled or in use. The impact includes potential kernel panics or system crashes due to scheduling while atomic errors, leading to denial of service (DoS) conditions. This can disrupt critical services, especially in environments relying on high-availability network connections or load balancing via MPTCP. Confidentiality and integrity impacts are less direct but could arise if attackers exploit the DoS to cause failovers or trigger recovery mechanisms that might be leveraged in complex attack chains. The vulnerability's concurrency nature means it could be triggered by crafted network traffic or high connection request volumes, potentially from internal or external sources. European organizations with data centers, cloud infrastructure, or telecom providers using Linux-based systems with MPTCP support are at risk of service interruptions. Given the increasing adoption of MPTCP in mobile networks and enterprise environments for improved resilience and throughput, the vulnerability could affect critical infrastructure components. The lack of known exploits reduces immediate risk, but the complexity of the bug and kernel-level impact warrant prompt attention to avoid operational disruptions.

Organizations should promptly update Linux kernels to versions where this vulnerability is patched, applying vendor-supplied fixes or mainline kernel updates that include the correction to mptcp_pm_nl_append_new_local_addr. If immediate patching is not feasible, consider disabling MPTCP functionality temporarily to eliminate exposure, especially on critical servers and network devices. Network administrators should monitor kernel logs for BUG messages related to scheduling while atomic errors as indicators of attempted exploitation or triggering of the race condition. Implement rate limiting or filtering on connection requests that could trigger parallel MPTCP endpoint creation, particularly if endpoints advertise differing internal and external addresses. Conduct thorough testing of network configurations that use MPTCP to identify and mitigate conditions that may exacerbate the race. Additionally, ensure robust system monitoring and automated recovery mechanisms to minimize downtime if kernel panics occur. Collaborate with Linux distribution vendors and security teams to track patch availability and deployment status. Avoid custom kernel modifications that might interfere with the official fix or introduce regressions in MPTCP handling.