In the Linux kernel, the following vulnerability has been resolved:
net: mpls: clear inner_protocol when the last label is popped
skb_mpls_push() records the pre-encapsulation network header once, gated
on !skb->inner_protocol. skb_mpls_pop() never clears that record, so it
outlives the encapsulation it describes.
Open vSwitch can then re-push MPLS onto a packet whose
inner_network_header still points at the older, deeper offset: push a
label, pop every label, recirculate (ovs_flow_key_update() re-derives
key->eth.type and resets network_header, but leaves inner_*), then push
again. ovs_fragment() trusts the record:
<pre>
skb->network_header = skb->inner_network_header;
</pre>
so skb_network_offset() goes negative. The bound check is signed:
<pre>
if (skb_network_offset(skb) > MAX_L2_LEN)
</pre>
a negative offset passes it, and prepare_frag() widens the value:
<pre>
unsigned int hlen = skb_network_offset(skb);
memcpy(&data->l2_data, skb->data, hlen);
</pre>
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
prepare_frag+0x3df/0x4e0
ovs_fragment+0x589/0x7e0
do_output+0x4ce/0x5e0
do_execute_actions+0x55d2/0x7b30
ovs_execute_actions+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 inner_protocol once the packet is no longer MPLS, so a later push
re-records the current header. net/sched/act_mpls.c is the only other
skb_mpls_pop() caller and gets the same fix; sch_frag.c saves and
restores inner_protocol around fragmentation in the same way OVS does.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - The stale inner_network_header comes from OVS flow actions (push_mpls, pop_mpls, recirc, push_mpls) that the attacker installs over the ovs_flow/ovs_packet generic netlink families. No field of a received packet causes the bad offset, so the vector is local netlink rather than the wire.
AC:L - The attacker chooses the flow action sequence and the oversized packet that sends do_output into ovs_fragment(). skb_mpls_pop() then deterministically leaves inner_protocol set, and the negative offset always passes the signed MAX_L2_LEN check, so nothing depends on timing or outside state.
PR:L - The OVS datapath, vport, flow and packet genl operations use GENL_UNS_ADMIN_PERM with netnsok=true. That means CAP_NET_ADMIN inside an unprivileged user and network namespace (unshare -Urn) is enough to create a datapath, install the flows and execute packets.
UI:N - No victim action is needed. The attacker installs the flows and injects or sends the packet themselves inside their own namespace.
S:U - The overflow corrupts memory of the same kernel that performs the check. This is ordinary in-kernel memory corruption and crosses no hypervisor or IOMMU boundary.
C:H - prepare_frag() turns a negative skb_network_offset() into an unsigned hlen of about 4 GiB and memcpy()s attacker packet bytes past the 30-byte per-CPU ovs_frag_data.l2_data. The write covers exec_level, owner, bh_lock and the per-CPU data that follows, and memory corruption of this kind can be leveraged for information disclosure.
I:H - This is an out-of-bounds write of attacker-controlled skb data into the per-CPU ovs_pcpu_storage and the per-CPU memory after it, including a task_struct pointer (owner) and lock state. The corruption stays in place if the oops happens in process context (OVS_PACKET_CMD_EXECUTE).
A:H - The runaway memcpy in prepare_frag() always runs until it hits an unmapped per-CPU page and oopses, as the fix's reproducer shows (write fault in memcpy from prepare_frag/ovs_fragment). The attacker can repeat this at will.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The stale inner_network_header comes from OVS flow actions (push_mpls, pop_mpls, recirc, push_mpls) that the attacker installs over the ovs_flow/ovs_packet generic netlink families. No field of a received packet causes the bad offset, so the vector is local netlink rather than the wire.
AC:L - The attacker chooses the flow action sequence and the oversized packet that sends do_output into ovs_fragment(). skb_mpls_pop() then deterministically leaves inner_protocol set, and the negative offset always passes the signed MAX_L2_LEN check, so nothing depends on timing or outside state.
PR:L - The OVS datapath, vport, flow and packet genl operations use GENL_UNS_ADMIN_PERM with netnsok=true. That means CAP_NET_ADMIN inside an unprivileged user and network namespace (unshare -Urn) is enough to create a datapath, install the flows and execute packets.
UI:N - No victim action is needed. The attacker installs the flows and injects or sends the packet themselves inside their own namespace.
S:U - The overflow corrupts memory of the same kernel that performs the check. This is ordinary in-kernel memory corruption and crosses no hypervisor or IOMMU boundary.
C:H - prepare_frag() turns a negative skb_network_offset() into an unsigned hlen of about 4 GiB and memcpy()s attacker packet bytes past the 30-byte per-CPU ovs_frag_data.l2_data. The write covers exec_level, owner, bh_lock and the per-CPU data that follows, and memory corruption of this kind can be leveraged for information disclosure.
I:H - This is an out-of-bounds write of attacker-controlled skb data into the per-CPU ovs_pcpu_storage and the per-CPU memory after it, including a task_struct pointer (owner) and lock state. The corruption stays in place if the oops happens in process context (OVS_PACKET_CMD_EXECUTE).
A:H - The runaway memcpy in prepare_frag() always runs until it hits an unmapped per-CPU page and oopses, as the fix's reproducer shows (write fault in memcpy from prepare_frag/ovs_fragment). The attacker can repeat this at will.
CVSS 3.1