CVE-2026-72444: flow_dissector: check device type before reading ETH_ADDRS

In the Linux kernel, the following vulnerability has been resolved:

flowdissector: check device type before reading ETHADDRS

skbflowdissect() unconditionally reads 12 bytes from ethhdr(skb) when FLOWDISSECTORKEYETHADDRS is requested. This assumes the skb has a valid Ethernet header at macheader, which is not always the case.

The problem can be triggered by: 1. Creating a TUN device in L3 mode (IFFTUN, hardheaderlen=0) 2. Attaching a multiq qdisc with a flower filter matching on ethsrc 3. Sending a packet through AFPACKET

Since TUN in L3 mode has no link-layer header, macheader points to the L3 data area. The flow dissector reads 12 bytes of uninitialized skb memory, which then propagates through flsetmaskedkey() and is used as a rhashtable lookup key in fllookup(), 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 == ARPHRDETHER, which ensures only true Ethernet-framed packets have their addresses read. This is more precise than the previous hardheaderlen >= 12 check, which would incorrectly pass for non-Ethernet link types like IPoIB (ARPHRDINFINIBAND, hardheaderlen=24) and FDDI (hardheaderlen=21) whose L2 headers are not in Ethernet format. Additionally check skbmacheaderwasset() to guard against the pathological case where macheader is the unset sentinel (~0U), which would cause ethhdr() to return a wild pointer.

For the actmirred 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.