CVE-2026-74667: Linux Vulnerability

Description

In the Linux kernel, the following vulnerability has been resolved: net/packet: reset the MAC header on the packet-socket transmit path packet_parse_headers() resets the MAC header only for a SOCK_RAW frame whose socket did not bind a protocol. A protocol-bound SOCK_RAW socket, any SOCK_DGRAM frame, and the legacy SOCK_PACKET path therefore leave skb->mac_header unset here. For frames sent via __dev_queue_xmit() this is harmless: it resets the MAC header unconditionally. But the packet-socket PACKET_QDISC_BYPASS path uses dev_direct_xmit(), which does not, so the frame reaches ndo_start_xmit() with the MAC header unset. A driver that reads eth_hdr(skb) on transmit then dereferences skb->head + (u16)~0, an out-of-bounds access ~64 KiB past the head -- the same class fixed for one consumer in commit f5089008f90c ("macsec: do not read an unset MAC header in macsec_encrypt()"). packet_parse_headers() runs only on the transmit path, where skb->data points at the start of the L2 header for every packet-socket type regardless of its length: SOCK_RAW and SOCK_PACKET carry a user-supplied header and SOCK_DGRAM has one built by dev_hard_header(). Reset the MAC header unconditionally, mirroring __dev_queue_xmit(), so the frame is anchored on the bypass path too. Found by 0sec (https://0sec.ai) using automated source analysis; verified against source and matched to the macsec KASAN report in f5089008f90c. Compile-tested.

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

Vendor	Product	Versions
Linux	Linux	>= 75c65772c3d18447d62d3aca5f91b06c16cc25e4, < 1e43a1d66615f411d427f9df1f46dd049d9e3681; >= 75c65772c3d18447d62d3aca5f91b06c16cc25e4, < 4057853a91fb796c4f47c7d1baf1aa085394148e; >= 75c65772c3d18447d62d3aca5f91b06c16cc25e4, < 2610ed4e86a4590234a9d70518c469751c5af231; >= 75c65772c3d18447d62d3aca5f91b06c16cc25e4, < b47ba8fe6e1d2df8c92048de5afafd059447dc30; >= 75c65772c3d18447d62d3aca5f91b06c16cc25e4, < 284f3e7a3f1a743fdf89e304fd1f19d5ffcff46d; >= 75c65772c3d18447d62d3aca5f91b06c16cc25e4, < 971aa7d99242bbf09513e27b7a243f0b29ff23ae; >= 75c65772c3d18447d62d3aca5f91b06c16cc25e4, < fdd4d7d52358a58e351dd9d82530c04eba8ccd7a; >= 75c65772c3d18447d62d3aca5f91b06c16cc25e4, < c2707480cfbf19c7619acc9c089d17f20869821f
Linux	Linux	5.1

References

Timeline

Published: Aug 22, 2026
Last Modified: Aug 22, 2026
Status: Received

Frequently Asked Questions

What is CVE-2026-74667?

In the Linux kernel, the following vulnerability has been resolved: net/packet: reset the MAC header on the packet-socket transmit path packet_parse_headers() resets the MAC header only for a SOCK_RAW frame whose socket did not bind a protocol. A protocol-bound SOCK_RAW socket, any SOCK_DGRAM frame, and the legacy SOCK_PACKET path therefore leave skb->mac_header unset here. For frames sent via __dev_queue_xmit() this is harmless: it resets the MAC header unconditionally. But the packet-socket PACKET_QDISC_BYPASS path uses dev_direct_xmit(), which does not, so the frame reaches ndo_start_xmit() with the MAC header unset. A driver that reads eth_hdr(skb) on transmit then dereferences skb->head + (u16)~0, an out-of-bounds access ~64 KiB past the head -- the same class fixed for one consumer in commit f5089008f90c ("macsec: do not read an unset MAC header in macsec_encrypt()"). packet_parse_headers() runs only on the transmit path, where skb->data points at the start of the L2 header for every packet-socket type regardless of its length: SOCK_RAW and SOCK_PACKET carry a user-supplied header and SOCK_DGRAM has one built by dev_hard_header(). Reset the MAC header unconditionally, mirroring __dev_queue_xmit(), so the frame is anchored on the bypass path too. Found by 0sec (https://0sec.ai) using automated source analysis; verified against source and matched to the macsec KASAN report in f5089008f90c. Compile-tested.

How severe is CVE-2026-74667?

Severity scoring for CVE-2026-74667 is pending analysis.

How do I fix CVE-2026-74667?

Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →