UBUNTU-CVE-2026-72444: Medium severity ubuntu/linux-aws vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 6.8.0-147.147 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 6.8.0-1067.70 - Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 6.8.0-1069.76 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.16~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 6.8.0-1066.74 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 6.8.0-1052.56 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38~24.04.4 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 6.8.0-1067.68 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 6.8.0-147.147.1 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 6.8.0-1036.39 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 6.8.0-1064.67 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1~24.04.1 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 6.8.0-1033.38 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 6.8.1-1062.63 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1067.70+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-147.147+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79+fips1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-38.38 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1016.16 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1008.9 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Compensating control
In __skb_flow_dissect(), guard Ethernet-address extraction with skb_mac_header_was_set() and gate the memcpy on dev->type == ARPHRD_ETHER; zero the ETH_ADDRS key for non-Ethernet devices, including TUN devices in L3 mode and act_mirred redirects to non-Ethernet devices.
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
The issue requires local access with low privileges. Systems running the listed Ubuntu kernel packages are relevant when they use a layer-3 TUN device, traffic control classification, and AF_PACKET traffic injection.
What conditions are needed to trigger it?
An attacker needs to create a TUN device in L3 mode, attach a multiq qdisc with a flower filter matching eth_src, and send a packet through AF_PACKET. The L3 TUN device has no link-layer header, causing the flow dissector to read uninitialized skb memory when Ethernet-address keys are requested.
Is rejecting the affected flower filter when it is created an effective mitigation?
No. TC filter blocks can be shared by arbitrary devices, so a filter initially installed for an Ethernet device can later classify traffic on a headerless device; the device association is not fixed when the filter is added.
What can be done before applying the fix?
Avoid the triggering combination: do not classify L3 TUN traffic with a multiq qdisc and flower filters that match eth_src. Restrict untrusted local users from creating or controlling TUN devices, traffic-control filters, and AF_PACKET sockets where possible.
How can administrators identify potentially affected configurations?
Inspect hosts for TUN devices operating in L3 mode and for multiq qdiscs using flower filters that request Ethernet source-address matching. Shared TC filter blocks also need review because they may be attached to headerless devices after filter creation.