CVE-2026-97612: net: mpls: clear inner_protocol when the last label is popped
In the Linux kernel, the following vulnerability has been resolved:
net: mpls: clear innerprotocol when the last label is popped
skbmplspush() records the pre-encapsulation network header once, gated on !skb->innerprotocol. skbmplspop() never clears that record, so it outlives the encapsulation it describes.
Open vSwitch can then re-push MPLS onto a packet whose innernetworkheader still points at the older, deeper offset: push a label, pop every label, recirculate (ovsflowkeyupdate() re-derives key->eth.type and resets networkheader, but leaves inner), then push again. ovsfragment() trusts the record:
skb->networkheader = skb->innernetworkheader;
so skbnetworkoffset() goes negative. The bound check is signed:
if (skbnetworkoffset(skb) > MAXL2LEN)
a negative offset passes it, and preparefrag() widens the value:
unsigned int hlen = skbnetworkoffset(skb); memcpy(&data->l2data, skb->data, hlen);
which is a ~4GiB memcpy out of a 30-byte per-CPU buffer.
Reproduced on v7.3-rc1. RDX is the truncated length, (unsigned int)(-8):
BUG: unable to handle page fault for address: ffffe8ffffc16000 #PF: supervisor write access in kernel mode Oops: 0002 [#1] SMP KASAN NOPTI RIP: 0010:memcpy+0x8/0x20 RDX: 00000000fffffff8 RSI: ffff888105d732db RDI: ffffe8ffffc16000 preparefrag+0x3df/0x4e0 ovsfragment+0x589/0x7e0 dooutput+0x4ce/0x5e0 doexecuteactions+0x55d2/0x7b30 ovsexecuteactions+0xea/0x450
Same root-cause shape as commit 975b5b067f52 ("ipv6: sr: restore network header before routing and forwarding"): a stale network header offset reaching a consumer that widens it. Here it originates in the MPLS push/pop path.
Clear innerprotocol once the packet is no longer MPLS, so a later push re-records the current header. net/sched/actmpls.c is the only other skbmplspop() caller and gets the same fix; schfrag.c saves and restores innerprotocol around fragmentation in the same way OVS does.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to the failing path?
The described path involves Open vSwitch processing packets that have MPLS labels pushed, all labels popped, recirculated, and then have MPLS pushed again. The issue depends on stale inner-header state surviving that sequence.
What must happen for the memory-safety failure to occur?
After MPLS labels are fully removed, Open vSwitch must recirculate the packet and later fragment it after another MPLS push. Fragmentation trusts the stale inner network-header offset, allowing a negative offset to become a very large unsigned copy length.
What symptoms could indicate that this issue has been triggered?
The provided reproduction caused a kernel-mode page fault and an Oops under KASAN. The failure involves a roughly 4 GiB memcpy into a 30-byte per-CPU buffer, so crashes or KASAN reports in the OVS fragmentation path may be relevant.