CVE-2026-46170

What it actually does

This flaw is a local denial-of-service condition in the Linux kernel Multipath TCP (MPTCP) path manager retransmission handling for ADD_ADDR messages. During ADD_ADDR retransmission, the kernel holds a socket reference through timer handling. Under a last-reference condition, incorrect socket reference release and timer cleanup behavior can cause the kernel to wait indefinitely while attempting to stop the same timer from within its own timer handler. The practical technical result is a kernel hang or severe availability failure triggered from local context by a user able to exercise the affected MPTCP code path.

Why it matters to the business

Successful exploitation can make an affected Linux system unresponsive or unavailable, disrupting workloads, services, containers, or network functions running on that host. Because the attack requires local privileges and there is currently no known public exploit or KEV listing, the immediate internet-scale risk is low; however, shared Linux systems, multi-user servers, CI/CD runners, container hosts, and environments where untrusted users can run code should treat this as an availability risk. The low EPSS score indicates limited observed exploitation likelihood, but kernel denial-of-service bugs can still be operationally significant where uptime is critical.

How an attack unfolds

An attacker first obtains local code execution or a low-privileged local account on an affected Linux system. They then exercise MPTCP functionality in a way that causes ADD_ADDR retransmission and manipulates timing or socket lifecycle conditions so the retransmission timer handler runs while holding what becomes the last socket reference. When the handler attempts to release the socket and cleanup timer state, the vulnerable kernel path can enter an indefinite wait while trying to stop the timer from its own timer context. This can cause the affected kernel thread or system to hang, resulting in denial of service. There is no indication from the supplied intelligence that this vulnerability enables privilege escalation, data theft, or remote unauthenticated compromise.

How to fix it

Apply the Linux kernel update that includes the MPTCP fix for ADD_ADDR retransmission socket reference and timer handling. Because no exact fixed versions were provided, use the corrected kernel packages from the operating system vendor or distribution security channel and prioritize systems where MPTCP is enabled or local users can run untrusted code. If immediate patching is not possible, reduce exposure by disabling MPTCP where it is not required, restricting local shell or workload execution to trusted users, limiting untrusted container privileges, and applying standard host hardening controls. Reboot into the patched kernel after installation; merely installing kernel packages is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm remediation by verifying that systems are running a vendor kernel build containing the MPTCP ADD_ADDR retransmission fix, not just that the package is installed. Check the active kernel with `uname -a` or distribution inventory tooling and compare it against the vendor advisory for this issue. Validate whether MPTCP is enabled using sysctl or kernel configuration checks such as `sysctl net.mptcp.enabled` where supported. If MPTCP is not required, confirm it is disabled after mitigation. For exposure validation, identify Linux assets running affected kernel versions with MPTCP available and local user or untrusted workload access. Where practical, perform validation in a test environment only; do not attempt denial-of-service reproduction on production systems.

Typical attack path

1. Gain local access to an affected Linux system as an unprivileged or otherwise low-privileged user.
2. Confirm that the kernel supports and permits use of Multipath TCP.
3. Create or manipulate MPTCP sockets to trigger ADD_ADDR advertisement and retransmission behavior.
4. Force the vulnerable timing condition where the ADD_ADDR retransmission timer releases the last socket reference.
5. Cause the kernel timer/socket cleanup path to wait indefinitely, degrading or halting system availability.

How to detect it

This issue is primarily a denial-of-service condition, so post-exploitation evidence is likely to appear as stability symptoms rather than clear intrusion artifacts. Review kernel logs, system journals, crash dumps, watchdog events, and monitoring telemetry for hangs, soft lockups, blocked tasks, timer stalls, or MPTCP-related messages preceding an outage. Useful sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, netconsole output, kdump/vmcore data, hypervisor reset records, and availability monitoring alerts. Investigate local user activity, container launches, and processes creating MPTCP sockets around the time of instability. Because exploitation may leave no durable file artifact and can culminate in a hang requiring reboot, absence of logs does not rule out attempted exploitation. No named threat actors, ransomware campaigns, or public exploit maturity were provided, so detection should focus on host telemetry and anomalous local MPTCP usage rather than known campaign indicators.

• mptcp
• ADD_ADDR
• soft lockup
• hard LOCKUP
• watchdog: BUG: soft lockup
• kernel: INFO: task
• blocked for more than
• rcu: INFO: rcu_preempt detected stalls
• BUG: unable to handle kernel
• Kernel panic
• Oops:
• sk_stop_timer_sync
• sk_reset_timer
• sock_put
• __sock_put
• /proc/sys/net/mptcp/enabled
• net.mptcp.enabled

What your security team should do

• Prioritize patching shared Linux hosts, container platforms, developer workstations, bastion systems, CI/CD runners, and any servers where untrusted or semi-trusted local users can execute code.
• Verify the running kernel version after maintenance windows and reboot systems into the fixed kernel.
• Disable MPTCP on systems that do not require it, especially where rapid kernel patching is not feasible.
• Review local access controls and reduce opportunities for untrusted users or containers to exercise kernel networking features.
• Monitor for unexplained hangs, soft lockups, kernel timer stalls, or MPTCP-related warnings until patching is complete.
• Track vendor advisories for exact fixed kernel package versions because upstream kernel CVE records may not provide distribution-specific version mappings.