CVE-2026-31669

What it actually does

This is a Linux kernel memory-safety flaw in the Multipath TCP implementation for IPv6 subflows. MPTCP IPv6 child sockets can be allocated from a generic kmalloc cache instead of the TCPv6 socket slab cache that is safe for lockless RCU lookups. Under concurrent socket teardown and established-connection hash table lookup, the kernel can dereference memory after it has been freed in __inet_lookup_established. The result is kernel memory corruption that can plausibly lead to denial of service through kernel panic and, in a worst case, arbitrary kernel memory access or code execution depending on exploit reliability and platform hardening.

Why it matters to the business

Systems running affected Linux kernels with MPTCP and IPv6 exposed to untrusted networks may be vulnerable to unauthenticated remote attacks that disrupt service or compromise the operating system kernel. The CVSS score is critical, but public exploitation signals are currently low: EPSS is 0.00459, unchanged over 30 days, there is no CISA KEV listing, no known ransomware use, and no exploit maturity reported. Organizations should still prioritize internet-facing, high-availability, routing, load-balancing, container-host, and service-provider Linux systems where MPTCP may be enabled because successful exploitation could cause outages or full host compromise.

How an attack unfolds

An attacker targets a Linux system that supports IPv6 MPTCP connections. They initiate or induce MPTCP traffic that creates IPv6 subflow child sockets, then drive connection churn and timing-sensitive concurrent lookups by rapidly opening, closing, and reusing connections. Because the affected MPTCP IPv6 subflow sockets are allocated from kmalloc-4k without SLAB_TYPESAFE_BY_RCU, a freed child socket can be immediately reused while another CPU is still performing a lockless established-socket lookup under RCU. If the race is won, __inet_lookup_established accesses stale memory. A basic exploit may crash the kernel; a more advanced exploit would attempt to shape heap reuse so the stale socket pointer references attacker-influenced data, potentially turning the use-after-free into kernel memory corruption with higher-impact consequences. No public exploitation or named threat actor activity is currently indicated by the provided intelligence.

How to fix it

Upgrade to a Linux kernel package that contains the upstream fix for "mptcp: fix slab-use-after-free in __inet_lookup_established." Because exact fixed package versions were not provided, use the fixed kernel releases from the relevant Linux distribution or appliance vendor and verify that their changelog references this MPTCP IPv6 subflow initialization fix or the associated CVE. Where immediate patching is not possible, reduce exposure by disabling MPTCP if it is not required, for example through the supported distribution mechanism such as setting net.mptcp.enabled=0 where available, and persist the setting across reboots. Also restrict untrusted network access to services that can accept MPTCP connections, limit IPv6 exposure where operationally feasible, and ensure kernel hardening features, crash recovery, and rapid reboot procedures are in place. Mitigations should be treated as temporary; patching the kernel is the durable fix.

How to confirm the fix worked

Confirm the running kernel version and installed kernel package are at or above the vendor-fixed release, then reboot into the fixed kernel and verify with uname -a and the package manager. Review the vendor kernel changelog or advisory for a reference to CVE-2026-31669, MPTCP, tcpv6_prot_override, SLAB_TYPESAFE_BY_RCU, or "mptcp: fix slab-use-after-free in __inet_lookup_established." Check whether MPTCP is enabled with sysctl net.mptcp.enabled where supported, and verify whether IPv6 and MPTCP-capable services are exposed. If using mitigation instead of patching, validate that net.mptcp.enabled is 0 after reboot and that MPTCP negotiation is no longer observed in packet captures. Exposure cannot be reliably ruled out by a remote banner check alone because this is kernel behavior dependent on configuration and traffic path.

Typical attack path

1. Identify a reachable Linux system running an affected kernel with IPv6 and MPTCP enabled or available to the targeted service.
2. Establish TCP connections that negotiate or exercise MPTCP IPv6 subflows.
3. Create high connection churn by repeatedly opening, closing, and re-establishing MPTCP subflows to trigger socket allocation and free paths.
4. Race socket teardown against lockless established-connection hash lookups performed under RCU.
5. Trigger stale access in __inet_lookup_established after the freed MPTCP IPv6 child socket memory has been reused.
6. Cause a kernel crash or attempt controlled heap reuse for more severe kernel memory corruption.

How to detect it

Look for evidence of kernel memory corruption or instability around IPv6 MPTCP traffic. Primary sources are dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, vmcore analysis, kdump output, and centralized syslog or EDR telemetry that records kernel panics. Search for KASAN or slab use-after-free reports naming __inet_lookup_established, MPTCP, tcpv6, tcpv6_prot_override, or kmalloc-4k. Also review network telemetry for unusual bursts of short-lived IPv6 TCP connections, repeated MPTCP negotiation attempts, or spikes in connection resets immediately before a kernel crash or reboot. Absence of these artifacts does not prove the vulnerability was not exercised, especially on systems without KASAN, persistent kernel logging, or crash dump retention.

• BUG: KASAN: slab-use-after-free in __inet_lookup_established
• slab-use-after-free in __inet_lookup_established
• __inet_lookup_established
• mptcp_subflow
• tcpv6_prot_override
• kmalloc-4k
• SLAB_TYPESAFE_BY_RCU
• MPTCP
• kernel BUG
• general protection fault
• Oops:
• Kernel panic
• BUG: unable to handle page fault
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• journalctl -k
• net.mptcp.enabled

What your security team should do

• Inventory Linux systems running kernels with MPTCP support, prioritizing internet-facing servers, network appliances, load balancers, container hosts, and systems accepting IPv6 traffic.
• Patch affected systems with vendor-fixed kernel packages and reboot into the fixed kernel as the primary remediation.
• If patching is delayed, disable MPTCP where not required and restrict untrusted IPv6/TCP access to exposed services.
• Monitor kernel logs for use-after-free, KASAN, Oops, panic, or general protection fault messages involving __inet_lookup_established, MPTCP, tcpv6, or kmalloc-4k.
• Hunt for unexplained reboots, kernel panics, or crashes correlated with bursts of IPv6 TCP/MPTCP connection churn.
• Because the issue is not currently in KEV and EPSS remains low, prioritize based on actual exposure, but do not defer remediation on critical externally reachable Linux infrastructure.
• Ensure crash dumps, persistent journald or remote syslog, and kernel panic artifacts are retained so exploitation attempts are not lost after reboot.