CVE-2026-89555: mpls: reload header after pskb_may_pull()
In the Linux kernel, the following vulnerability has been resolved:
mpls: reload header after pskbmaypull()
mplsselectmultipath() calls mplsmultipathhash() to choose a nexthop when an MPLS route has multiple nexthops. While walking the MPLS label stack, the hash routine caches hdr for the current label. After finding the bottom-of-stack label, it calls pskbmaypull() before reading the inner IP header.
If an skb is constructed with the inner IP header in nonlinear data and insufficient tailroom in the linear head, pskbmaypull() calls pskbexpandhead() to replace the skb head and free the old one. This leaves hdr pointing to freed memory. The IPv6 path can invalidate hdr again when it performs a second pull for the larger header.
The issue was found through static analysis. A reproducer sending a legal Geneve packet through a bareudp/MPLS multipath setup triggered the same KASAN report in 2 of 2 unpatched runs:
BUG: KASAN: slab-use-after-free in mplsselectmultipath Read of size 1 at addr ffff88800ecc6e20 by task ksoftirqd/1/23
Call Trace: mplsselectmultipath mplsforward netifreceiveskblistcore netifreceiveskblistinternal napicompletedone grocellpoll napipoll netrxaction
Freed by task 23: kfree pskbexpandhead pskbpulltail mplsselectmultipath
Reload hdr from the current skb head after each successful pull before deriving the inner IPv4 or IPv6 header pointer.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the Linux kernel source/package so that after each successful pskb_may_pull() the MPLS code reloads the header pointer (reload hdr from the current skb head after each successful pull), specifically in the path that performs multiple pulls/expansion during MPLS label walking and multipath nexthop selection.
Linux kernel MPLS multipath (function: mpls_select_multipath) mpls: reload header after pskb_may_pull() = Apply the kernel code fix that reloads the header after each successful pskb_may_pull() to prevent use-after-free (kASAN slab-use-after-free: mpls_select_multipath / mpls_select_multipath() calling mpls_multipath_hash())
Event History
Frequently Asked Questions
What network configuration must be present for this issue to be reachable?
The affected path is MPLS multipath selection, which is used when an MPLS route has multiple nexthops. The reported reproducer sent a legal Geneve packet through a bareudp/MPLS multipath setup.
What packet condition triggers the use-after-free?
The inner IP header must be in nonlinear skb data while the linear skb head has insufficient tailroom. Under that condition, pskb_may_pull() can replace and free the skb head, leaving a cached MPLS header pointer referring to freed memory; IPv6 processing can trigger another invalidating pull.
How might this appear on an affected system?
The reported symptom is a KASAN slab-use-after-free report in mpls_select_multipath, with the read occurring during MPLS forwarding. The report was observed in ksoftirqd while processing received packets.