CVE-2026-74667: net/packet: reset the MAC header on the packet-socket transmit path
In the Linux kernel, the following vulnerability has been resolved:
net/packet: reset the MAC header on the packet-socket transmit path
packetparseheaders() resets the MAC header only for a SOCKRAW frame whose socket did not bind a protocol. A protocol-bound SOCKRAW socket, any SOCKDGRAM frame, and the legacy SOCKPACKET path therefore leave skb->macheader unset here.
For frames sent via devqueuexmit() this is harmless: it resets the MAC header unconditionally. But the packet-socket PACKETQDISCBYPASS path uses devdirectxmit(), which does not, so the frame reaches ndostartxmit() with the MAC header unset. A driver that reads ethhdr(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 macsecencrypt()").
packetparseheaders() 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: SOCKRAW and SOCKPACKET carry a user-supplied header and SOCKDGRAM has one built by devhardheader(). Reset the MAC header unconditionally, mirroring devqueuexmit(), 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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1
Event History
Frequently Asked Questions
What conditions are required to trigger the out-of-bounds access?
A frame must be transmitted through the packet-socket PACKET_QDISC_BYPASS path, which uses dev_direct_xmit() without resetting the MAC header. The receiving network driver's transmit callback must also read eth_hdr(skb) or otherwise rely on the MAC header being set.
Which packet socket types can reach the affected state?
The affected cases are protocol-bound SOCK_RAW sockets, all SOCK_DGRAM packet-socket frames, and the legacy SOCK_PACKET path. An unbound SOCK_RAW socket was already handled by the prior conditional MAC-header reset.
How can I assess exposure if I cannot patch immediately?
Review whether workloads use packet sockets with PACKET_QDISC_BYPASS and whether the selected transmit driver reads the Ethernet header through eth_hdr(skb). Avoiding the qdisc-bypass transmit path causes frames to use __dev_queue_xmit(), which resets the MAC header unconditionally.