CVE-2026-72444
HighCVSS 7.8Exploitation Probability (EPSS)
Low risk4th percentile - higher than 4% of all known CVEs
Summary
A vulnerability in the Linux kernel's flow_dissector mechanism unconditionally reads Ethernet addresses (ETH_ADDRS) from the packet header, even when the device has no link-layer header (e.g., TUN in L3 mode). This leads to reading uninitialized skb memory, which can be used as a key in a rhashtable, potentially causing unpredictable TC filter matching. The fix adds checks for device type (ARPHRD_ETHER) and whether the MAC header is set.
Risk Assessment
The risk involves potential exploitation of uninitialized memory to manipulate packet classification in TC filters, which could lead to unauthorized access or network disruption. An attacker can send a specially crafted packet via AF_PACKET to influence filter behavior.
Recommendation
It is recommended to immediately update the Linux kernel to a version containing the fix. If not possible, restrict access to creating TUN devices and using flower filters on shared TC blocks.
Original NVD description (English source)
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.