CVE-2026-74667 in Linux
Summary
by MITRE • 08/22/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel packet socket implementation contains a logic flaw in the header parsing routine that leads to an out-of-bounds memory access under specific transmission conditions. The vulnerability resides within the net/packet subsystem, specifically affecting how the MAC header pointer is managed for different types of sockets during the transmit path processing. While recent updates addressed similar issues in other network drivers such as macsec, a parallel oversight remained in the packet socket code where the initialization of the skb->mac_header field was not performed consistently across all socket configurations and transmission paths. This inconsistency creates a scenario where network device drivers may attempt to access memory locations that are outside the valid bounds of the sk_buff structure, potentially leading to kernel crashes or arbitrary code execution depending on the specific driver implementation and system state at the time of exploitation.
The technical root cause lies in the packet_parse_headers function which is responsible for preparing packets for transmission. This function correctly resets the MAC header only when dealing with a SOCK_RAW frame that has not bound to a specific protocol. However, it fails to perform this reset for three other common scenarios: frames sent via protocol-bound SOCK_RAW sockets, any SOCK_DGRAM frames, and traffic traversing the legacy SOCK_PACKET path. In these cases, the skb->mac_header field remains unset or contains stale data from previous operations. Under normal circumstances, this oversight is mitigated because most network transmission paths utilize __dev_queue_xmit(), which unconditionally resets the MAC header before passing the packet to the device driver. Consequently, standard traffic flows are unaffected by this defect as the subsequent layer ensures proper initialization of the pointer.
The vulnerability becomes critical when packets traverse the PACKET_QDISC_BYPASS path, which utilizes dev_direct_xmit() instead of __dev_queue_xmit(). The dev_direct_xmit function bypasses certain queueing disciplines and does not perform the unconditional reset of the MAC header that is present in the standard transmission path. As a result, frames sent through this optimized route reach the ndo_start_xmit callback of the network device driver with an unset or invalid skb->mac_header value. When a driver attempts to read Ethernet headers using eth_hdr(skb), it calculates the address by adding the length field interpreted as an unsigned short to the head pointer. Since the header is uninitialized, this calculation often results in dereferencing memory at offset ~64 KiB past the start of the buffer, triggering an out-of-bounds access error similar to those previously identified and fixed in macsec encryption routines.
From a security perspective, this vulnerability represents a classic case of improper initialization leading to invalid memory access. It aligns with CWE-908 which describes the use of uninitialized resource values that can lead to unpredictable behavior or crashes. Furthermore, because it involves network packet processing within the kernel, it falls under ATT&CK technique T1496 related to Resource Hijacking if exploited for denial-of-service, though more severe implications exist depending on how an attacker might leverage the out-of-bounds read to leak sensitive kernel memory contents. The impact ranges from local denial of service through kernel panics to potential privilege escalation if the out-of-bounds access allows reading or writing arbitrary kernel memory addresses. This is particularly dangerous in virtualized environments where network drivers are frequently loaded and unloaded, increasing the attack surface for such logic errors.
Mitigation strategies primarily involve applying the upstream Linux kernel patch that resolves this issue by modifying packet_parse_headers to unconditionally reset the MAC header on the transmit path. This change mirrors the behavior of __dev_queue_xmit() ensuring consistency regardless of whether the PACKET_QDISC_BYPASS flag is set or which socket type is being used. System administrators should ensure their systems are updated with kernel versions that include this fix, as it addresses a fundamental inconsistency in network stack header management. For environments where immediate patching is not feasible, restricting access to packet sockets and disabling QDisc bypass features can reduce the likelihood of triggering the vulnerable code path, although complete mitigation requires the source code correction provided by the Linux kernel maintainers.