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.