A recently disclosed race condition in the Linux kernel’s Multipath TCP (MPTCP) code — tracked as CVE‑2025‑40257 — can lead to a slab-use-after-free while deleting a timer, and upstream maintainers have patched the bug by adding RCU protection and clarifying the timer logic; operators should treat this as a stability/availability risk for hosts that run MPTCP or host multi‑tenant networking workloads and apply vendor kernel updates as soon as they are available.
Conclusion: CVE‑2025‑40257 exposes a narrow but real race window in MPTCP timer handling that can precipitate a kernel use‑after‑free; upstream maintainers have fixed it by adding RCU protection and clarifying the code path, and operators should ensure their kernels or appliance images include the fix and reboot into patched kernels — especially on multi‑tenant, cloud, and gateway systems where kernel crashes create outsized operational risk.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background
What is MPTCP and why timers matter
Multipath TCP (MPTCP) is an extension to TCP that allows a single logical TCP connection to use multiple network paths simultaneously. It is used to increase throughput, provide redundancy, and permit seamless failover across interfaces such as Wi‑Fi and LTE. Like the rest of the Linux networking stack, MPTCP uses a mix of timers, workqueues, and reference-counted objects to schedule retransmissions, control timers for address announcements (ADD_ADDR / REMOVE_ADDR), and clean up per‑address state. Timers are particularly sensitive: deleting or stopping a kernel timer requires correct synchronization with any code that may free the object that contains that timer; incorrect ordering or missing lifetime protection can produce use‑after‑free (UAF) crashes or KASAN reports. This is the precise failure class exposed by the CVE.How this bug was found
The flaw surfaced via syzbot, the kernel fuzzing infrastructure, which reported a KASAN slab-use-after-free trace rooted in timer deletion code. The kernel backtrace in public issue records shows __timer_delete_sync and sk_stop_timer_sync in the call stack, with the timer deletion originating from net/mptcp/pm.c in the mptcp_pm_del_add_timer path. The reproduce trace and review by maintainers confirmed a race where one CPU invoked sk_stop_timer_sync(sk, &entry->add_timer) while another CPU or path could be freeing the enclosing entry structure.Overview of the vulnerability (CVE‑2025‑40257)
- Affected subsystem: Linux kernel — net/mptcp (MPTCP path manager).
- Root cause: race between timer-stop code and concurrent free of the timer’s container (entry), allowing sk_stop_timer_sync to operate on freed memory.
- Symptom when triggered: KASAN slab-use-after-free reports and kernel oopses (availability impact).
- Fix: add RCU protection around the entry pointer usage and make the timer-stop intent clearer by replacing a confusingly named variable with a boolean (rename add_timer → stop_timer).
- Reported-by: syzbot; patch contributed and discussed on the netdev mailing list.
Technical anatomy — what exactly goes wrong
The timer deletion race (plain language)
The MPTCP path manager keeps per‑address entries that include a per‑entry timer (add_timer) used to retransmit ADD_ADDR messages or otherwise manage address announcement lifecycles. Two different code paths can reach the logic that stops and deletes that timer:- Fast packet paths or incoming TCP processing can invoke mptcp_pm_del_add_timer as part of processing incoming options.
- Control or management code (for example, netlink-driven removal flows) can concurrently remove address entries and free them.
Why sk_stop_timer_sync is sensitive
sk_stop_timer_sync invokes lower-level timer deletion paths that assume the timer object remains alive for the duration of the deletion. If the enclosing structure (entry) may be freed concurrently, the deletion routine will look at fields or metadata that are already reclaimed, causing the KASAN violation. Timers in Linux are often stored as embedded structs inside larger objects; the safe deletion pattern requires either:- owning or reference-counting the outer object so it cannot be freed until after timer deletion, or
- using a synchronization primitive (for example RCU) that guarantees the storage backing the pointer is kept stable during the critical window.
The upstream fix — what maintainers changed
- Add RCU protection: The patch wraps the lookup/usage of the entry pointer in RCU read-side protection (rcu_read_lock/rcu_read_unlock and rcu_dereference semantics) so that readers attempting to stop a timer cannot observe a freed entry while the RCU grace period handling guarantees safe reclamation. This prevents the narrow window where sk_stop_timer_sync would reference freed memory.
- Rename and clarify the variable: The code’s prior variable name add_timer was misleading (it was short for “additional address signalling retransmission timer”). The change replaces it with a boolean named stop_timer which makes the intent of the code clear: whether the code is stopping the timer. This reduces cognitive load for future reviewers and avoids accidental misuse.
- Minimal, surgical approach: The patch is intentionally small and focused on synchronization semantics; it does not alter higher‑level MPTCP behavior. That keeps regression risk low and simplifies backporting to stable kernels.
Cross‑checking and corroboration
Multiple independent trackers and sources reflect the same facts:- The NVD entry summarizes the KASAN trace and the fact that RCU protection was added to fix mptcp_pm_del_add_timer.
- Public kernel mailing list (netdev) discussion contains the patch submission, maintainer review, and the explicit message “Add RCU protection to fix this issue,” along with the variable rename explanation and syzbot attribution. This is the primary engineering artifact describing the changes.
- Vendor advisories and vulnerability aggregators (for example SUSE and public CVE mirrors) mirror the same summary and list the CVE for tracking in distribution updates. These corroborating entries confirm vendors are aware and mapping the patch into downstream packages.
Practical impact and exploitability
Who should care most
- Cloud providers, multi‑tenant VM hosts, and containers where untrusted tenants can exercise local networking paths are high priority — a kernel oops in a host or VM can cause tenant disruptions or trigger failovers.
- VPN gateways, mobile routers, or appliances that enable MPTCP features (or carry vendor kernels derived from upstream MPTCP code) should be prioritized for verification and patching.
- Development and CI systems that run kernel-debug configurations with KASAN or other dynamic checks may see these issues surface more often and should be patched to avoid noisy failures.
Likely impact
- Primary impact: availability (kernel oops, host instability, service disruption).
- Confidentiality/integrity: there’s no public proof-of-concept converting this race into reliable remote code execution or privilege escalation at disclosure time; however, kernel lifecycle races can, in theory, be leveraged in complex exploitation chains if an attacker can precisely groom heap and timing. Treat that as a theoretical escalation vector rather than an observed remote RCE.
Exploitability posture
- Attack vector: local/adjacent (an attacker needs a way to trigger the timer stop and the concurrent free — for example, by controlling network traffic, netlink messages, or running code in the guest on virtualized hosts).
- Privileges required: low in the sense of local code execution; the race is not trivially weaponizable remotely without local or guest access.
- Public PoC: none published at disclosure in mainstream trackers; absence of PoC is not a guarantee of safety.
Detection and hunting guidance
Short, practical checks to find whether your estate is being affected or marginally exposed:- Search kernel logs for KASAN/UAF traces referencing the timer path:
- journalctl -k | egrep -i 'KASAN|__timer_delete_sync|sk_stop_timer_sync|mptcp_pm_del_add_timer'
- Look for netdev oops messages with mptcp or mptcp_pm_worker in the stack trace.
- If you run KASAN-enabled kernels (test/dev), a reproducible KASAN log that includes the snippet shown in public traces (sk_stop_timer_sync → mptcp_pm_del_add_timer → mptcp_incoming_options) is a smoking gun.
- Kernel oopses can auto‑reboot the machine, losing log context; configure persistent journal and kdump/dump collection to preserve traces.
- Correlate oopses with recent netlink/management operations or heavy MPTCP traffic, since the race arises from two distinct code paths both able to manipulate address entries.
Mitigation and remediation
Immediate actions (short term)
- Inventory: identify hosts that run kernels with MPTCP enabled (grep for CONFIG_MPTCP or check /boot/config-$(uname -r).
- Search logs: use the detection steps above to surface recent oopses tied to the trace in question.
- Risk-based prioritization: prioritize multi‑tenant, cloud, or network‑facing infrastructure for immediate patching and reboot.
Apply the patch (recommended)
- Install the vendor-supplied kernel update that references CVE‑2025‑40257 or the corresponding upstream commit.
- Reboot hosts into the patched kernel — timer/stack fixes require a reboot to remove the vulnerable code from running memory.
- For vendors that publish backport details: verify package changelogs list the upstream commit or explicitly mention the CVE.
Workarounds if patching is delayed
- Reduce exposure: isolate affected networking hosts from untrusted tenants, restrict access to netlink or other management interfaces where feasible.
- Limit MPTCP usage: if your environment allows, disable MPTCP features or modules on critical hosts until you can deploy a fixed kernel. This is a blunt tool and may not be practical in all cases.
- Harden local execution: reduce the set of users/processes that can exercise untrusted networking scenarios on shared hosts.
How to verify the fix landed (technical checklist)
- Kernel source check: inspect net/mptcp/pm.c for RCU read‑side guards around entry accessor code and for the changed boolean name (stop_timer). If you see rcu_read_lock/rcu_dereference or explicit rcu handling in the mptcp_pm_del_add_timer path, the upstream pattern is present.
- Git/commit verification: compare your kernel’s git history to the upstream patch series; the netdev mailing-list patch discussion includes the commit message and Fixes: tag that identifies the original commit being addressed. Matching that Fixes: or patch ID to your packaged kernel changelog is the authoritative check.
- Package changelog: your distribution’s kernel package changelog or security advisory should reference CVE‑2025‑40257 once backported; confirm that the package you installed contains the backport before rolling wide.
Risk assessment — strengths and residual concerns
Strengths of the fix
- Targeted and minimal: adding RCU protection is a conventional, low‑risk remedy for this class of racing pointer‑use bug. The patch does not change higher‑level MPTCP semantics, reducing regression risk.
- Backportable: because the change is small, downstream vendors can reasonably backport it into stable kernel branches, accelerating remediation for widespread deployments.
Residual risks
- Long tail of unpatched devices: embedded vendors, OEM images, and appliances with slow update cycles may remain exposed for months; these often represent the highest operational risk.
- Exploitation uncertainty: although no PoC was published at disclosure, lifecycle races in kernel networking code have historically sometimes been weaponized by skilled exploiters. Until wide patching is complete, do not assume the absence of a PoC equates to no threat.
Operational playbook (concise)
- Identify: run uname -r and check for CONFIG_MPTCP and module presence.
- Prioritize: treat multi‑tenant hosts, network appliances, and cloud VM hosts as high priority.
- Patch: obtain the vendor kernel packages that list CVE‑2025‑40257 or the upstream commit, deploy to staging, test, then roll out.
- Reboot: schedule reboots into patched kernels (this is required).
- Monitor: watch kernel logs for remaining KASAN traces or oopses; verify no new mptcp-related WARNs appear.
- Vendor follow-up: for appliance vendors, request timelines for kernel image updates and apply network segmentation until updates are available.
For Windows users and mixed estates
Even Windows-centric administrators should care: Linux kernels run broadly across hybrid infrastructures (VMs, containers, WSL, edge appliances). A kernel oops in any Linux VM or appliance can disrupt services consumed by Windows systems (file shares, authentication relays, VPNs). Inventory any Linux elements in your environment — especially gateway appliances and VMs that perform MPTCP or heavy path management — and coordinate patching with the teams that manage those images. Distribution advisories listed the CVE for mapping into downstream package updates; follow your vendor’s guidance to patch and reboot.Final notes and recommended next steps
- Treat CVE‑2025‑40257 primarily as an availability issue: the documented KASAN slab‑UAF leads to kernel oopses/crashes, and the upstream mitigation adds RCU protection to eliminate that race window.
- Prioritize patching for hosts with MPTCP enabled, multi‑tenant exposure, or those that host critical networking functions.
- Preserve diagnostics: enable persistent journal and crashdump collection to capture any KASAN or oops traces that occur before you can patch — those traces make root-cause confirmation and vendor triage far easier.
- Verify fixes by checking upstream commit presence in your kernel source or package changelogs; do not rely solely on generic CVE presence — match commits or explicit vendor advisory notes before marking a host as remediated.
Conclusion: CVE‑2025‑40257 exposes a narrow but real race window in MPTCP timer handling that can precipitate a kernel use‑after‑free; upstream maintainers have fixed it by adding RCU protection and clarifying the code path, and operators should ensure their kernels or appliance images include the fix and reboot into patched kernels — especially on multi‑tenant, cloud, and gateway systems where kernel crashes create outsized operational risk.
Source: MSRC Security Update Guide - Microsoft Security Response Center
