CVE-2026-89555: Linux Kernel MPLS Use-After-Free Vulnerability

CVE-2026-89555 Overview

CVE-2026-89555 is a use-after-free vulnerability in the Linux kernel Multiprotocol Label Switching (MPLS) forwarding path. The flaw resides in mpls_select_multipath(), which calls mpls_multipath_hash() to choose a nexthop for MPLS routes with multiple nexthops. When processing a nonlinear socket buffer (skb), a call to pskb_may_pull() can invoke pskb_expand_head() and free the original skb head, leaving the cached hdr pointer dangling. Subsequent reads of the inner IPv4 or IPv6 header dereference freed memory. Attackers on the network path can trigger the condition with crafted Geneve packets routed through a bareudp/MPLS multipath setup.

Critical Impact
Remote attackers can trigger a kernel-space use-after-free that may lead to denial of service or arbitrary code execution in kernel context on hosts processing MPLS multipath traffic.

Affected Products

Linux kernel versions prior to the fix commits referenced in git.kernel.org
Systems configured with MPLS multipath routing (CONFIG_MPLS_ROUTING)
Deployments using bareudp/Geneve encapsulation with MPLS forwarding

Discovery Timeline

2026-09-11 - CVE-2026-89555 published to NVD
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-89555

Vulnerability Analysis

The vulnerability is a use-after-free [CWE-416] in the MPLS multipath selection routine. mpls_multipath_hash() walks the MPLS label stack and caches a pointer to the MPLS header in a local variable hdr. After locating the bottom-of-stack label, the function calls pskb_may_pull() to ensure the inner IP header is present in the linear region of the skb. When the skb has the inner IP header in nonlinear (paged) data and the linear head lacks sufficient tailroom, pskb_may_pull() internally calls pskb_expand_head(), which allocates a new head buffer and frees the old one. The cached hdr pointer now references freed slab memory. The IPv6 code path compounds the issue by performing a second pull for the larger IPv6 header, which can invalidate hdr again.

Root Cause

The root cause is failure to reload a cached header pointer after an operation that may reallocate the skb linear data. Kernel networking code must treat any pointer into skb->data as invalidated after pskb_may_pull(), pskb_expand_head(), or __pskb_pull_tail() succeed. The fix reloads hdr from the current skb head after each successful pull before deriving the inner IPv4 or IPv6 header pointer.

Attack Vector

The vulnerability is reachable over the network without authentication. A reproducer that sent a legal Geneve packet through a bareudp/MPLS multipath configuration triggered a KASAN slab-use-after-free report in mpls_select_multipath on 2 of 2 unpatched runs. The freed allocation traces back to kfree → pskb_expand_head → __pskb_pull_tail invoked from the same function that later reads the stale pointer. Exploitation requires the target host to have MPLS forwarding enabled and to receive traffic that lands on an MPLS route with multiple nexthops. See the Kernel Commit d9640239 for the corrective patch.

No verified public proof-of-concept code is available. The vulnerability was identified through static analysis and confirmed with a Geneve-over-bareudp reproducer described in the upstream commit message.

Detection Methods for CVE-2026-89555

Indicators of Compromise

KASAN reports containing BUG: KASAN: slab-use-after-free in mpls_select_multipath in kernel logs
Call traces showing mpls_forward → mpls_select_multipath followed by a slab free path through pskb_expand_head
Unexpected kernel oops, panic, or softirq crashes on hosts running MPLS forwarding with bareudp or Geneve tunnels

Detection Strategies

Inventory Linux hosts with CONFIG_MPLS_ROUTING=y and audit whether mpls_router is loaded (lsmod | grep mpls)
Correlate kernel crash telemetry with MPLS forwarding activity to identify hosts hitting the buggy code path
Compare running kernel versions against the fix commits (29e63b8, 49d38c1, aa4fe0b, b1c0783, bfaaff9, d82b90a, d964023, fed638a)

Monitoring Recommendations

Forward dmesg and /var/log/kern.log to a centralized SIEM and alert on KASAN, oops, and softirq stack traces referencing mpls_
Monitor for anomalous inbound Geneve or bareudp traffic on hosts not expected to terminate such tunnels
Track MPLS route configuration changes and multipath route additions across the fleet

How to Mitigate CVE-2026-89555

Immediate Actions Required

Apply the upstream kernel fix commits or your distribution's backported patch as soon as vendor updates are available
Where the MPLS module is not required, unload it with modprobe -r mpls_router and blacklist it to remove the attack surface
Restrict ingress of Geneve and bareudp traffic to trusted sources using firewall or eBPF policies

Patch Information

The fix reloads the MPLS header pointer from skb->data after every successful pskb_may_pull() call in mpls_multipath_hash(). Upstream patches are tracked under the following commits: 29e63b8d, 49d38c1b, aa4fe0b4, b1c0783b, bfaaff99, d82b90a3, d9640239, and fed638a2. Consult your distribution's security tracker for backport availability.

Workarounds

Disable MPLS forwarding by setting net.mpls.platform_labels=0 where MPLS routing is not required
Remove MPLS multipath routes so mpls_select_multipath() is not invoked on the ingress path
Block or drop unexpected Geneve (UDP/6081) and bareudp traffic at the network edge until patched kernels are deployed

bash

# Disable MPLS platform label table (removes MPLS forwarding capability)
sysctl -w net.mpls.platform_labels=0

# Blacklist the MPLS router module to prevent auto-load
echo 'blacklist mpls_router' | sudo tee /etc/modprobe.d/blacklist-mpls.conf
sudo modprobe -r mpls_router

# Drop unexpected Geneve tunnel traffic at the host firewall
sudo iptables -A INPUT -p udp --dport 6081 -j DROP