CVE-2026-72444

flow_dissector: check device type before reading ETH_ADDRS

HIGH
7.8
CVSS Score
Published: August 15, 2026 at 05:56 AM UTC
Updated: October 16, 2026 at 07:17 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.8
Exploit prediction
EPSS 0.1%
SSVC
No known exploit

Description

In the Linux kernel, the following vulnerability has been resolved: flow_dissector: check device type before reading ETH_ADDRS __skb_flow_dissect() unconditionally reads 12 bytes from eth_hdr(skb) when FLOW_DISSECTOR_KEY_ETH_ADDRS is requested. This assumes the skb has a valid Ethernet header at mac_header, which is not always the case. The problem can be triggered by: 1. Creating a TUN device in L3 mode (IFF_TUN, hard_header_len=0) 2. Attaching a multiq qdisc with a flower filter matching on eth_src 3. Sending a packet through AF_PACKET Since TUN in L3 mode has no link-layer header, mac_header points to the L3 data area. The flow dissector reads 12 bytes of uninitialized skb memory, which then propagates through fl_set_masked_key() and is used as a rhashtable lookup key in __fl_lookup(), as reported by KMSAN. Rejecting the filter in the control path (at tc filter add time) is not feasible because TC filter blocks can be shared between arbitrary devices -- a filter installed on an Ethernet device may later classify packets on a headerless device through a shared block. The device association is not fixed at filter creation time. Fix this by gating the memcpy on dev->type == ARPHRD_ETHER, which ensures only true Ethernet-framed packets have their addresses read. This is more precise than the previous hard_header_len >= 12 check, which would incorrectly pass for non-Ethernet link types like IPoIB (ARPHRD_INFINIBAND, hard_header_len=24) and FDDI (hard_header_len=21) whose L2 headers are not in Ethernet format. Additionally check skb_mac_header_was_set() to guard against the pathological case where mac_header is the unset sentinel (~0U), which would cause eth_hdr() to return a wild pointer. For the act_mirred redirect case (Ethernet packet redirected to a non-Ethernet device sharing a TC block), zeroing the key is the correct behavior: the packet is now being classified on the target device, where Ethernet address matching is not semantically meaningful. Note: on non-Ethernet devices, the zeroed key will match a filter configured with all-zero MAC addresses. This is an improvement over the previous behavior where uninitialized memory could randomly match any filter.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

4.267a900cc0436d74e7ff89042371760def087680d
Vendor states this is fixed in 0fe6455b8e1a22414f39c07bc90a1df12b52ec74 (fixed)
Vendor states this is fixed in 594c90b197141944f25991b8314de5c26ee27a7e (fixed)
Vendor states this is fixed in 825de39f0c35a112148799b3cbe45af3766c018a (fixed)
Vendor states this is fixed in 9a65860959db594dfc1820c7fdc09285fb7556bf (fixed)
Vendor states this is fixed in bf6e8af2c8be77489bedeae9f8a9654cb710e500 (fixed)
Vendor states this is fixed in c6d3bcb0f934d4297ac5fa1c8656ae40694fb601 (fixed)
Vendor states this is fixed in 4.2 (unaffected)
Vendor states this is fixed in 6.1.178 (unaffected)
Vendor states this is fixed in 6.12.97 (unaffected)
Vendor states this is fixed in 6.18.40 (unaffected)
Vendor states this is fixed in 6.6.145 (unaffected)
Vendor states this is fixed in 7.1.5 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

SSVC — Action Prioritization

SSVCNo known exploitNot automatableTotal impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

7.8HIGHLinux
Vector?

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card