Skip to main content
VulnerabilityPublished Updated

CVE-2026-72444: Linux kernel · flow_dissector: check device type before reading ETH_ADDRS __skb_flow_dissect()

Affects Linux kernelSource GCVE Database

0

Not known to be exploited · CVSS 7.8 High · fixed in 6.8.0-147.147 : patch Linux kernel soon.

Data as of 28 Oct 2026, 00:59 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
Patch
Available – fixed in 6.8.0-147.147, 6.8.0-1067.70, 7.0.0-1014.14~24.04.1 +26
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 15 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
Ubuntu 26.04 LTSlinuxpkg:deb/ubuntu/linux?arch=source&distro=resoluteOther threatsAffected
  • <7.0.0-38.38
Fixed in
  • 7.0.0-38.38
Ubuntu 26.04 LTSlinux-awspkg:deb/ubuntu/linux-aws?arch=source&distro=resoluteOther threatsAffected
  • <7.0.0-1014.14
Fixed in
  • 7.0.0-1014.14
Ubuntu 26.04 LTSlinux-azurepkg:deb/ubuntu/linux-azure?arch=source&distro=resoluteOther threatsAffected
  • <7.0.0-1017.17
Fixed in
  • 7.0.0-1017.17
Ubuntu 26.04 LTSlinux-azure-fdepkg:deb/ubuntu/linux-azure-fde?arch=source&distro=resoluteOther threatsAffected
  • <7.0.0-1016.16
Fixed in
  • 7.0.0-1016.16
Ubuntu 26.04 LTSlinux-gcppkg:deb/ubuntu/linux-gcp?arch=source&distro=resoluteOther threatsAffected
  • <7.0.0-1014.14
Fixed in
  • 7.0.0-1014.14
Ubuntu 26.04 LTSlinux-gkepkg:deb/ubuntu/linux-gke?arch=source&distro=resoluteOther threatsAffected
  • <7.0.0-1008.9
Fixed in
  • 7.0.0-1008.9

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

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.

References

Community reviews

Loading reviews…