CVE-2026-31669: mptcp: fix slab-use-after-free in __inet_lookup_established
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix slab-use-after-free in __inet_lookup_established
The ehash table lookups are lockless and rely on
SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability
during RCU read-side critical sections. Both tcp_prot and
tcpv6_prot have their slab caches created with this flag
via proto_register().
However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into
tcpv6_prot_override during inet_init() (fs_initcall, level 5),
before inet6_init() (module_init/device_initcall, level 6) has
called proto_register(&tcpv6_prot). At that point,
tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab
remains NULL permanently.
This causes MPTCP v6 subflow child sockets to be allocated via
kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab
cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so
when these sockets are freed without SOCK_RCU_FREE (which is
cleared for child sockets by design), the memory can be
immediately reused. Concurrent ehash lookups under
rcu_read_lock can then access freed memory, triggering a
slab-use-after-free in __inet_lookup_established.
Fix this by splitting the IPv6-specific initialization out of
mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called
from mptcp_proto_v6_init() before protocol registration. This
ensures tcpv6_prot_override.slab correctly inherits the
SLAB_TYPESAFE_BY_RCU slab cache.
Security readout for executives and security teams
Plain-English summary
A Linux kernel memory-safety flaw can occur when MPTCP creates IPv6 subflow sockets. Under concurrent network activity, the kernel may access memory after it has been freed and reused. This could cause crashes or potentially compromise confidentiality and integrity, although the supplied sources do not demonstrate successful exploitation.
Executive priority
Treat as an accelerated kernel-patching issue, especially on network-facing or MPTCP-enabled Linux systems. Begin inventory and vendor confirmation immediately. Critical severity supports urgent remediation, but current evidence does not justify claiming an active campaign or confirmed remote code execution.
Technical view
MPTCP copied tcpv6_prot before its SLAB_TYPESAFE_BY_RCU cache existed, leaving tcpv6_prot_override.slab permanently NULL. IPv6 subflow children were consequently allocated from kmalloc-4k, which lacks the required RCU memory-stability property. Lockless established-socket lookups could then dereference freed memory. The fix delays IPv6-specific initialization until the correct slab cache is available.
Likely exposure
Exposure is limited to affected Linux kernels where MPTCP IPv6 subflows can be created. The supplied version data identifies affected releases but is insufficient for confidently mapping every distribution kernel or backport. Confirm installed kernel builds and vendor patch status rather than relying only on upstream version numbers.
Exploitation context
The supplied CVSS is 9.8 and characterizes network reachability without privileges or user interaction. However, the vulnerable path requires MPTCP IPv6 subflow activity and a concurrent lookup/free condition. CVE-2026-31669 is not identified as KEV, and the supplied sources provide no evidence of active exploitation or a public exploit.
Researcher notes
The defect is an initialization-order violation affecting allocator selection and RCU lifetime guarantees. Assessment should focus on whether a vendor kernel includes the fix, not merely whether its version resembles an upstream release. The sources establish the use-after-free mechanism and correction but do not establish exploit reliability, observed attacks, or affected distribution-specific builds.
Mitigation direction
Install a vendor-supported kernel containing the applicable upstream stable fix.
Check distribution and appliance advisories for backported fixes and exact affected builds.
Prioritize systems using MPTCP with IPv6 or exposing relevant network services.
If patching is delayed, request vendor-supported temporary mitigations; none are established in the supplied sources.
Validation and detection
Record each system's kernel package, build identifier, distribution, and architecture.
Determine whether MPTCP and IPv6 subflows are enabled or operationally required.
Match vendor advisories and changelogs to the listed upstream stable fix commits.
After updating, verify the running kernel changed and the vendor marks the vulnerability resolved.
Review kernel logs for memory-safety faults or crashes; absence does not prove non-exposure.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-31669 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
10Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.