CVE-2026-99033: net/packet: guard the ll header push in packet_rcv_spkt()
In the Linux kernel, the following vulnerability has been resolved:
net/packet: guard the ll header push in packetrcvspkt()
packetrcvspkt() restores the link layer header with
skbpush(skb, skb->data - skbmacheader(skb));
That subtraction is only meaningful when the device actually has a link layer header. packetrcv() and tpacketrcv() both wrap it in devhasheader(), which is also the predicate the block comment at the top of the file states the restore in terms of; packetrcvspkt() 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->macheader at the 0xFFFF sentinel that allocskb() initialises it to. A CAN skb does: initcanskb() sets pkttype and ipsummed but does not reset the headers, and commit 9f10374bb024 ("can: remove private CAN skb headroom infrastructure") dropped the skbresetheader() calls that used to be there. skbmacheader() is then 0xFFFF, the length becomes a large negative number and skbpush() reports it through skbunderpanic() -- from softirq context, so it is a full system panic even with paniconoops=0:
skbuff: skbunderpanic: text:ffffffff8bd21bc1 len:-65455 put:-65471 head:... data:... tail:0x50 end:0x180 dev:can0 kernel BUG at net/core/skbuff.c:214! RIP: 0010:skbpanic+0x50/0x60 Call Trace: <IRQ> skbpush+0x38/0x40 packetrcvspkt+0xe1/0x170 netifreceiveskbcore.constprop.0+0x7e8/0xd30 ... Kernel panic - not syncing: Fatal exception in interrupt
The socket type is reachable: packetcreate() accepts SOCKPACKET alongside SOCKRAW and SOCKDGRAM behind the same CAPNETRAW check, and neither the socket length nor a capability check keeps it away from a CAN interface.
The missing skbresetheader() calls in initcanskb() 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 cansend() resets the headers on the way out. One SOCKPACKET 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 CONFIGCANSLCAN=y, differing only in this hunk.