CVE-2026-99033

In the Linux kernel, the following vulnerability has been resolved:

net/packet: guard the ll header push in packet rcv spkt()

packet rcv spkt() restores the link layer header with

skb push(skb, skb->data - skb mac header(skb));

That subtraction is only meaningful when the device actually has a link layer header. packet rcv() and tpacket rcv() both wrap it in dev has header(), which is also the predicate the block comment at the top of the file states the restore in terms of; packet rcv spkt() does not. commit d549699048b4 ("net/packet: fix packet receive on L3 devices without visible hard header") introduced the helper and changed the two call sites, and this one stayed behind.

A device without a visible ll header can leave skb->mac header at the 0xFFFF sentinel that alloc skb() initialises it to. A CAN skb does: init can skb() sets pkt type and ip summed but does not reset the headers, and commit 9f10374bb024 ("can: remove private CAN skb headroom infrastructure") dropped the skb reset * header() calls that used to be there. skb mac header() is then 0xFFFF, the length becomes a large negative number and skb push() reports it through skb under panic() -- from softirq context, so it is a full system panic even with panic on oops=0:

skbuff: skb under panic: text:ffffffff8bd21bc1 len:-65455 put:-65471 head:... data:... tail:0x50 end:0x180 dev:can0 kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb panic+0x50/0x60 Call Trace: skb push+0x38/0x40 packet rcv spkt+0xe1/0x170 netif receive skb core.constprop.0+0x7e8/0xd30 ... Kernel panic - not syncing: Fatal exception in interrupt

The socket type is reachable: packet create() accepts SOCK PACKET alongside SOCK RAW and SOCK DGRAM behind the same CAP NET RAW check, and neither the socket length nor a capability check keeps it away from a CAN interface.

The missing skb reset * header() calls in init can skb() are a regression in their own right and are being fixed separately, but a packet socket should not turn a link layer that did not initialise its mac header into a kernel panic. Guard the push the way the other two receive paths do.

Tested on v7.3-rc5 under QEMU with a slcan device on a pty, which is the driver RX path: vcan does not reproduce it, because can send() resets the headers on the way out. One SOCK PACKET socket bound to can0 and one frame written into the line discipline panics an unpatched kernel with the trace above; the same image with this patch prints no panic and powers off normally. Both kernels are this tree, defconfig plus CONFIG CAN SLCAN=y, differing only in this hunk.