CVE-2026-74701: net/openvswitch: check Ethernet header length in key_extract()
In the Linux kernel, the following vulnerability has been resolved:
net/openvswitch: check Ethernet header length in keyextract()
When a packet arrives on an ARPHRDNONE device (e.g. TUN), ovsflowkeyextract() trusts the user-provided skb->protocol field: if it is ETHPTEB, the packet is classified as MACPROTOETHERNET and keyextract() is called without ensuring the skb has ETHHLEN (14) bytes of linear data. keyextract() unconditionally pulls 2 ETHALEN bytes for MAC addresses and parseethertype() pulls 2 more, either of which triggers a kernel BUG in skbpull() when the linear area is too small.
kernel BUG at include/linux/skbuff.h:2848! RIP: 0010:keyextract+0xa7e/0xd90 net/openvswitch/flow.c:933 ovsflowkeyextract+0x419/0xa70 ovsvportreceive+0x222/0x390 netdevframehook+0x3e0/0x630 tungetuser+0x2d0c/0x38e0
Fixed by calling checkheader() in keyextract() before accessing the Ethernet header.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1
Event History
Frequently Asked Questions
Which systems are exposed to this condition?
Systems using Open vSwitch with packets arriving through an ARPHRD_NONE device are exposed. The described example is a TUN device, where a user-provided skb->protocol value can cause the packet to be treated as Ethernet.
What does an attacker need to trigger the failure?
An attacker needs to cause a packet with insufficient linear data for a 14-byte Ethernet header to be processed through the affected path, while skb->protocol is set to ETH_P_TEB. This causes Open vSwitch to access Ethernet header fields without first confirming that the header is present.
What is the impact of successful exploitation?
The insufficient packet length causes a kernel BUG in __skb_pull() while key_extract() processes MAC addresses or the EtherType. The provided data indicates a kernel crash condition.
How is the issue fixed?
The fix adds a check_header() call in key_extract() before Ethernet header data is accessed. This verifies that the required Ethernet header is available before parsing it.