Look up another CVE · open CVE-2026-72444 in the interactive tracker
CVE-2026-72444
flow_dissector: check device type before reading ETH_ADDRS
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem net/core. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-72444 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixed | 6.1.180-1 | Update the kernel and reboot. Fixed in 6.1.180-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
__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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/core/flow_dissector.c
- What this is
- NETWORKING [GENERAL]MAINTAINERS section matched on net/ · netdev@vger.kernel.org · Maintained
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS Debian linux-config packages
Signals
- Published
- 2026-08-15 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/core
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.2 | 6.1.178 | 0fe6455b8e1a |
| 4.2 | 6.6.145 | 9a65860959db |
| 4.2 | 6.12.97 | 594c90b19714 |
| 4.2 | 6.18.40 | c6d3bcb0f934 |
| 4.2 | 7.1.5 | 825de39f0c35 |
| 4.2 | 7.2 | bf6e8af2c8be |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is hit from TC flower classification (fl_classify) on packets injected locally via AF_PACKET through an L3 TUN with mq/flower qdisc; per kernel guidance TC/netlink qdisc paths are Local, not remotely reachable network stack handlers.
- AC:LAttack complexity, low
- Syzbot and the fix commit show reliable reproduction by creating an L3 TUN, attaching a multiq qdisc with a flower eth_src filter, and sending packets via AF_PACKET; the attacker controls every setup step with no races or rare kernel config.
- PR:LPrivileges required, low
- Exploitation requires CAP_NET_ADMIN to create/configure the TUN and install TC flower filters via rtnetlink, plus CAP_NET_RAW for AF_PACKET sockets; both capabilities are obtainable by an unprivileged user inside a user+network namespace (unshare -Urn).
- UI:NUser interaction, none
- No victim user action is required; exploitation uses attacker-controlled local syscalls (TUN ioctl, rtnetlink TC setup, AF_PACKET sendmsg) in a namespace they create.
- S:UScope, unchanged
- Impact stays within the kernel networking/TC subsystem of the host or attacker-controlled namespace; it does not cross VM, sandbox, or IOMMU security boundaries.
- C:HConfidentiality impact, high
- __skb_flow_dissect copies 12 bytes from eth_hdr(skb) when FLOW_DISSECTOR_KEY_ETH_ADDRS is set; on headerless devices (L3 TUN, ARPHRD_NONE) mac_header points at L3 data or unset headroom, leaking uninitialized or out-of-bounds kernel memory into flow keys used by __fl_lookup.
- I:HIntegrity impact, high
- Garbage eth address keys flow through fl_set_masked_key into rhashtable lookup and can spuriously match flower filters, invoking unintended TC actions (police drop, skb mark, act_mirred redirect) that alter packet handling beyond the attacker's own data.
- A:HAvailability impact, high
- When mac_header is the unset sentinel (~0U), eth_hdr() becomes a wild pointer and the memcpy can page-fault with a kernel oops/panic; even without fault, mis-matched filters can apply drop/redirect actions that deny or disrupt packet delivery.