CVE-2026-46137

What it actually does

This is a race condition in the Linux kernel Multipath TCP (MPTCP) path-manager ADD_ADDR retransmission timer. The vulnerable timer callback can run in softirq context without consistently holding the appropriate socket lock, allowing concurrent access to socket/MPTCP state while another execution path is using or modifying it. Depending on timing and kernel build/runtime conditions, this can cause corrupted MPTCP state, kernel warnings or crashes, denial of service, and potentially more severe memory-safety side effects if the race is shaped reliably. The CVSS vector indicates remote, unauthenticated, low-complexity exploitation with potential confidentiality, integrity, and availability impact, but no public exploit maturity is currently reported and EPSS is low.

Why it matters to the business

Systems running affected Linux kernels with MPTCP enabled may be exposed to remote attacks that could destabilize hosts or network services, potentially causing outages for applications relying on Linux networking. Because the issue is in the kernel, successful exploitation can affect the whole system rather than a single application. It is not currently listed in CISA KEV, not reported as ransomware-used, and has a low EPSS score, but the high CVSS rating and kernel-level impact justify timely remediation, especially on internet-facing Linux servers or environments where MPTCP is enabled.

How an attack unfolds

An attacker would target a Linux host that has an affected kernel and MPTCP support enabled. They would initiate or interact with MPTCP connections in a way that exercises the path-manager ADD_ADDR option and its retransmission timer. By causing timer callbacks and socket operations to occur concurrently, the attacker attempts to hit the window where the timer callback accesses MPTCP socket state without the required bottom-half-safe socket lock. If the race is won, the host may experience corrupted MPTCP state, kernel faulting, service disruption, or potentially broader kernel compromise depending on the exact memory effects and hardening configuration. In practice, reliable exploitation may require precise timing and kernel-version-specific behavior, and no public exploit has been reported in the supplied metadata.

How to fix it

Upgrade affected Linux kernels to a vendor-supported version that includes the upstream fix for the MPTCP path-manager ADD_ADDR retransmission timer locking issue. Because no exact fixed versions were provided, use the relevant distribution advisory or stable kernel release notes for the package in use and confirm the patch references the MPTCP change that uses bottom-half-safe socket locking in the ADD_ADDR retransmission timer path. Where immediate patching is not possible, reduce exposure by disabling MPTCP if it is not required, restricting inbound access to services that can negotiate MPTCP, and applying network controls that limit untrusted traffic to affected hosts. Reboot systems after kernel updates so the fixed kernel is actually running.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated by checking the active kernel version after reboot. Validate whether MPTCP is enabled using kernel sysctl and feature checks, such as the net.mptcp.enabled setting where available. Review vendor changelogs or package advisories to verify the applied kernel includes the MPTCP ADD_ADDR retransmission timer locking fix. For mitigations, confirm MPTCP is disabled or inaccessible from untrusted networks. After remediation, monitor kernel logs during MPTCP connection testing for absence of MPTCP-related warnings, lockdep reports, KASAN reports, general protection faults, or softirq/socket locking warnings.

Typical attack path

1. Identify Linux systems with affected kernel versions and MPTCP support available or enabled.
2. Establish network connectivity to a service or endpoint capable of negotiating MPTCP connections.
3. Create MPTCP sessions that trigger path-manager ADD_ADDR behavior.
4. Manipulate connection timing, retransmissions, and socket activity to force ADD_ADDR retransmission timer execution while the socket is concurrently in use.
5. Attempt to win the race condition in the softirq timer callback and corrupt or destabilize MPTCP socket state.
6. Observe effects such as connection disruption, kernel warnings, host crash, or other unintended kernel behavior.

How to detect it

To determine whether exploitation may already have occurred, review host kernel logs, persistent journal entries, crash dumps, netconsole output, and EDR/kernel telemetry for signs of MPTCP-related faults or abnormal softirq/socket locking behavior. Focus on systems with MPTCP enabled and exposed to untrusted networks. Look for kernel stack traces referencing MPTCP path-manager functions, ADD_ADDR processing, timer callbacks, socket locking warnings, KASAN/KCSAN race reports, general protection faults, kernel oopses, or unexpected reboots during periods of inbound MPTCP-capable traffic. Network telemetry may show repeated MPTCP session attempts, TCP options associated with MPTCP, or unusual connection churn before kernel instability, but packet-level evidence alone is not sufficient to prove exploitation. Because this is a race condition in kernel code, there may be no clean application-layer indicator; absence of logs does not rule out attempted exploitation, especially if the host crashed before logs were persisted.

• mptcp_pm_add_timer
• mptcp
• ADD_ADDR
• KCSAN: data-race
• KASAN:
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel BUG
• WARNING: CPU:
• Oops:
• softirq
• bh_lock_sock
• lockdep
• NETDEV WATCHDOG
• Kernel panic - not syncing

What your security team should do

• Prioritize patching internet-facing or untrusted-network-accessible Linux systems where MPTCP is enabled or may be used.
• Inventory Linux kernel versions and MPTCP enablement across servers, appliances, containers hosts, and network-facing infrastructure.
• If patching must be delayed, disable MPTCP where operationally acceptable and restrict exposure to MPTCP-capable services.
• Monitor kernel logs and crash telemetry for MPTCP-related stack traces, socket locking warnings, kernel panics, and softirq faults.
• Track Linux distribution advisories for exact fixed kernel package versions and ensure systems are rebooted into the patched kernel.
• Because exploit maturity is currently reported as none and EPSS is low, balance urgency against exposure, but treat affected internet-facing kernels as high priority due to kernel-level impact.