Access of Uninitialized Pointer Affecting kernel-devel package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CENTOS10-KERNELDEVEL-18988989
- published20 Aug 2026
- disclosed15 Aug 2026
Introduced: 15 Aug 2026
NewCVE-2026-72444 (opens in a new tab)How to fix?
There is no fixed version for Centos:10 kernel-devel.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-devel package and not the kernel-devel package as distributed by Centos.
See How to fix? for Centos:10 relevant fixed versions and status.
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:
- Creating a TUN device in L3 mode (IFF_TUN, hard_header_len=0)
- Attaching a multiq qdisc with a flower filter matching on eth_src
- 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
- https://bugzilla.redhat.com/show_bug.cgi?id=2516571
- https://access.redhat.com/security/cve/CVE-2026-72444
- https://git.kernel.org/stable/c/0fe6455b8e1a22414f39c07bc90a1df12b52ec74
- https://git.kernel.org/stable/c/594c90b197141944f25991b8314de5c26ee27a7e
- https://git.kernel.org/stable/c/825de39f0c35a112148799b3cbe45af3766c018a
- https://git.kernel.org/stable/c/9a65860959db594dfc1820c7fdc09285fb7556bf
- https://git.kernel.org/stable/c/bf6e8af2c8be77489bedeae9f8a9654cb710e500
- https://git.kernel.org/stable/c/c6d3bcb0f934d4297ac5fa1c8656ae40694fb601