CVE-2026-74667

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