SEC.co
Emergency
MEDIUM 5.5

CVE-2026-46170

A flaw in the Linux kernel's MPTCP (Multipath TCP) path manager can cause a denial of service when certain network protocol messages are retransmitted. Specifically, when an ADD_ADDR message is resent, the kernel may mismanage internal reference counting for a socket object, potentially leading to a deadlock or crash. An unprivileged local user can trigger this condition, causing the affected system to become unresponsive.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.5 MEDIUM · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weaknesses (CWE)
—
Affected products
3 configuration(s)
Published / Modified
2026-05-28 / 2026-06-17

NVD description (verbatim)

In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: free sk if last When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(), and released at the end. If at that moment, it was the last reference being held, the sk would not be freed. sock_put() should then be called instead of __sock_put(). But that's not enough: if it is the last reference, sock_put() will call sk_free(), which will end up calling sk_stop_timer_sync() on the same timer, and waiting indefinitely to finish. So it is needed to mark that the timer is done at the end of the timer handler when it has not been rescheduled, not to call sk_stop_timer_sync() on "itself".

5 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-46170 exists in the Linux kernel's MPTCP protocol implementation, specifically in the ADD_ADDR retransmission handler. The vulnerability involves improper socket reference counting during timer operations. When sk_reset_timer() holds a socket reference during ADD_ADDR retransmission, the handler's cleanup code fails to account for scenarios where this is the final reference. Calling __sock_put() instead of sock_put() means the socket is not freed when it should be. Worse, if sock_put() is called when it is the last reference, sk_free() invokes sk_stop_timer_sync() on the same timer object currently executing, resulting in a synchronous deadlock waiting for the timer to complete. The fix requires marking the timer as finished when not rescheduled to prevent recursive sk_stop_timer_sync() calls.

Business impact

While the CVSS score of 5.5 (MEDIUM) limits severity to denial of service conditions, the impact is locally triggered and affects availability only. Organizations running MPTCP-enabled kernels on multi-user systems face risk of unprivileged users crashing critical services or rendering hosts unresponsive. Single-purpose systems or those without MPTCP enabled face minimal risk. Downtime from kernel crashes affects service delivery and recovery time objectives.

Affected systems

The Linux kernel is affected; all versions with MPTCP support are potentially vulnerable. The vulnerability requires local access and unprivileged execution capability. Systems must have MPTCP functionality enabled to be exploitable. Affected versions span the kernel codebase; consult your Linux distribution's security advisories for specific version ranges and backport information.

Exploitability

This vulnerability requires local system access and unprivileged user privileges (PR:L in CVSS). It cannot be exploited remotely. The condition is triggered during MPTCP ADD_ADDR retransmission, suggesting relatively straightforward triggering for users with shell access. No exploit is publicly disclosed in the KEV catalog. Attack complexity is low (AC:L), making it practical for a local attacker to reproduce deliberately or encounter accidentally through normal MPTCP operation.

Remediation

Apply security updates from your Linux distribution that include the fix for CVE-2026-46170. The upstream kernel fix involves correcting socket reference counting in the ADD_ADDR retransmission path and ensuring timer state is properly marked to prevent recursive synchronous cleanup. Verify against your vendor's advisory for specific patched kernel versions. Until patching, mitigate by restricting local shell access to trusted users if MPTCP functionality is not essential.

Patch guidance

Contact your Linux distribution (Red Hat, Ubuntu, Debian, SUSE, etc.) for security advisories listing patched kernel versions. Apply the recommended kernel update following your organization's change management procedures. Kernel updates typically require reboot. Test in non-production environments first to ensure compatibility with workloads. Verify the patch by checking the kernel version post-update and confirming the fix commit is present in your kernel's source or changelog.

Detection guidance

Monitor system logs for kernel crash dumps (kernel panic messages) or watchdog resets. Kernel BUG messages related to socket cleanup or timer handling in MPTCP code paths may indicate exploitation attempts. Use kernel debugging tools (crash dump analysis) to examine stack traces mentioning sk_reset_timer, ADD_ADDR, or sock_put. Audit local user activity and shell access logs for suspicious behavior patterns from unprivileged accounts. Network-level detection is limited; focus on endpoint behavior monitoring.

Why prioritize this

Prioritize based on your environment. High-priority if you run MPTCP-enabled kernels on multi-tenant or shared systems with untrusted local users, or if availability is critical. Lower priority for single-user systems, air-gapped hosts, or systems where MPTCP is disabled. The MEDIUM CVSS score and local-only requirement position this as important but not emergency.

Risk score, explained

CVSS 3.1 score of 5.5 (MEDIUM) reflects: local attack vector (AV:L) limiting scope, low complexity to trigger (AC:L), no privileges required beyond unprivileged user (PR:L), no user interaction (UI:N), scope unchanged (S:U), and availability impact only (A:H, C:N, I:N). The score appropriately reflects that this is a denial-of-service condition for local users without confidentiality or integrity compromise.

Frequently asked questions

Can this vulnerability be exploited remotely?

No. The vulnerability requires local system access and cannot be triggered over the network. It is limited to unprivileged local users with shell access to the affected system.

Do I need to patch if MPTCP is disabled on my systems?

MPTCP support must be enabled in the kernel for this vulnerability to be exploitable. If your kernel is compiled without MPTCP support or the feature is administratively disabled, you are not at risk. Check your kernel configuration or consult your system administrator.

What happens if this vulnerability is exploited?

Exploitation results in a denial of service—the affected service or kernel may hang or crash due to deadlock in socket cleanup. The system may require manual restart or watchdog-triggered reboot. No data is exposed, and the attacker gains no code execution or privilege escalation.

How do I know if my system is vulnerable?

Check your kernel version against your Linux distribution's security advisory for CVE-2026-46170. Most distributions publish advisories listing vulnerable kernel versions. Run `uname -r` to see your current kernel version, and compare it against the patched versions listed in the advisory for your distribution.

This analysis is based on the official CVE record and related security advisories. CVSS scores and severity ratings are provided by NIST/NVD. Patch availability and specific affected kernel versions vary by Linux distribution; verify patch status with your vendor's security advisory. No public exploit code is known for this vulnerability as of the publication date. This analysis does not constitute professional security advice; consult your internal security team or a qualified security consultant for risk assessment specific to your environment. Source: NVD (public-domain), retrieved 2026-07-07. Analysis generated by SEC.co (claude-haiku-4-5).

Affected vendors

linux

Related vulnerabilities