CVE-2026-46158

What it actually does

CVE-2026-46158 is a Linux kernel Multipath TCP (MPTCP) path manager flaw in the ADD_ADDR retransmission path. When an ADD_ADDR option is retransmitted, the socket reference count is incremented through timer handling, but certain early-return error paths fail to decrement that reference count. Repeatedly exercising the affected path can leak socket references and associated kernel resources, potentially causing resource exhaustion and local denial of service. The CVSS vector indicates local access with low attack complexity and low privileges, with impact limited to availability rather than confidentiality or integrity.

Why it matters to the business

Successful exploitation can degrade or disrupt Linux systems by exhausting kernel resources, leading to service instability, hung networking components, or host-level denial of service. The risk is highest on systems where untrusted local users, containers, workloads, or sandboxed processes can create or interact with MPTCP sockets. This issue is not listed in CISA KEV, has very low EPSS, and has no known public exploit maturity in the provided data, so it is generally a patch-management priority rather than an emergency internet-facing incident unless affected systems allow local untrusted execution.

How an attack unfolds

An attacker first needs local code execution or an account on an affected Linux system. They then create or manipulate MPTCP connections in a way that triggers ADD_ADDR retransmission behavior in the MPTCP path manager. Under specific error or edge conditions, the kernel takes an early return path after the socket was referenced by timer handling but before the reference is released. By repeatedly triggering this path, the attacker can cause reference-count leakage over time. As leaked references accumulate, kernel memory and socket-related resources may not be reclaimed, eventually degrading networking behavior or causing denial of service on the host.

How to fix it

Apply a Linux kernel update containing the upstream fix for the MPTCP ADD_ADDR retransmission socket reference-count leak. Because no exact fixed package versions were provided, use the fixed kernel versions supplied by the relevant Linux distribution or vendor advisory for CVE-2026-46158. After updating, reboot into the patched kernel and verify the active runtime kernel version, not only the installed package version. If immediate patching is not possible, reduce exposure by disabling MPTCP where it is not required, restricting local shell access, limiting untrusted container capabilities, applying resource controls such as cgroups and process limits, and monitoring for abnormal socket or memory growth. Disabling MPTCP may affect workloads that intentionally rely on Multipath TCP, so validate operational impact before broad deployment.

How to confirm the fix worked

Confirm exposure by checking whether the active kernel version is one identified by the operating system vendor as affected and whether MPTCP is enabled. On Linux systems, review the running kernel with `uname -r`, installed kernel package metadata, and vendor advisories. Check MPTCP status through sysctl or procfs where available, such as `net.mptcp.enabled` or `/proc/sys/net/mptcp/enabled`. Confirm remediation by rebooting into a vendor-fixed kernel and verifying that the running kernel matches the fixed advisory level. Where practical, run regression or stress tests for MPTCP workloads and confirm there is no abnormal growth in socket counts, kernel memory, slab allocations, or unreclaimed MPTCP-related resources during ADD_ADDR retransmission scenarios.

Typical attack path

1. Obtain local low-privileged access to an affected Linux host, container, or workload environment.
2. Confirm that the running kernel supports and has MPTCP enabled or reachable by local processes.
3. Create MPTCP sockets or connections capable of exercising ADD_ADDR path manager behavior.
4. Trigger ADD_ADDR retransmission and associated edge/error paths repeatedly.
5. Accumulate leaked socket references and unreclaimed kernel resources.
6. Cause local service degradation, network instability, or denial of service through resource exhaustion.

How to detect it

Look for evidence of local resource-exhaustion activity involving MPTCP rather than remote compromise. Useful sources include kernel logs, system journal logs, auditd or EDR process telemetry, container runtime logs, sysctl configuration history, and host performance metrics. Review `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, and `journalctl -k` for MPTCP warnings, socket allocation failures, out-of-memory events, soft lockups, or network stack instability. Correlate spikes in kernel memory, slab usage, socket counts, and MPTCP connection activity with local processes or containers. Search process execution telemetry for unusual custom binaries or scripts repeatedly creating MPTCP sockets. Because this vulnerability is a reference-count leak, exploitation may leave few deterministic artifacts; investigation should focus on repeated local MPTCP activity followed by unreclaimed socket/kernel memory growth or denial-of-service symptoms. No named threat actors, KEV exploitation, or ransomware use are identified in the provided data.

• net.mptcp.enabled = 1
• /proc/sys/net/mptcp/enabled
• MPTCP
• ADD_ADDR
• Out of memory
• oom-killer
• possible memory allocation failure
• TCP: out of memory
• socket: too many open files
• soft lockup
• kernel: BUG: soft lockup
• INFO: task
• blocked for more than
• /var/log/kern.log
• /var/log/syslog
• /var/log/messages

What your security team should do

• Prioritize patching affected Linux kernels on multi-user systems, container hosts, CI/CD runners, shared compute platforms, and systems running untrusted local workloads.
• Use vendor advisories to identify the exact fixed kernel packages for each Linux distribution, then verify systems have rebooted into the patched kernel.
• Inventory where MPTCP is enabled and disable it on systems that do not require Multipath TCP functionality.
• Apply compensating controls on systems awaiting reboot or patching, including restricting local access, reducing container privileges, and enforcing cgroup resource limits.
• Monitor for local denial-of-service symptoms, including unexplained kernel memory growth, rising socket counts, MPTCP-related warnings, soft lockups, or network stack instability.
• Treat exploitation likelihood as currently low based on very low EPSS, no KEV listing, and no known exploit maturity in the provided data, but still remediate through normal kernel security maintenance because exploitation requires only low-privileged local access.