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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.11-1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.10.273 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.113 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.57 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.11 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
azurelinux/kernelto a version that resolves this vulnerability.Fixed in 6.6.161.1-1 - Upgrade
Upgrade
ubuntu/linux-aws-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1069.74~22.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1073.82~22.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1071.78~22.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1073.81~22.04.1 - Upgrade
Upgrade
ubuntu/linux-ibm-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1069.70~22.04.1 - Upgrade
Upgrade
ubuntu/linux-lowlatency-hwe-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-149.149.1~22.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1067.71~22.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-149.149~22.04.2 - Upgrade
Upgrade
ubuntu/linux-realtime-6.8to a version that resolves this vulnerability.Fixed in 6.8.1-1064.65~22.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 6.8.0-149.149 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 6.8.0-1069.74 - Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.18~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 6.8.0-1073.82 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 6.8.0-1071.78 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1019.19~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 6.8.0-1073.81 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.19~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 6.8.0-1068.77 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 6.8.0-1053.57 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 6.8.0-1069.70 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 6.8.0-149.149.1 - Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 6.8.0-1067.70 - Upgrade
Upgrade
ubuntu/linux-nvidia-lowlatencyto a version that resolves this vulnerability.Fixed in 6.8.0-1067.70.1 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 6.8.0-1067.71 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.18~24.04.1 - Upgrade
Upgrade
ubuntu/linux-raspito a version that resolves this vulnerability.Fixed in 6.8.0-1068.72 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-43.43.1~24.04.2 - Upgrade
Upgrade
ubuntu/linux-vmwareto a version that resolves this vulnerability.Fixed in 6.8.0-1010.10 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 6.8.0-1036.41 - Upgrade
Upgrade
ubuntu/linux-raspi-realtimeto a version that resolves this vulnerability.Fixed in 6.8.0-2056.58 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 6.8.1-1064.65 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1069.74+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1073.82+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1073.81+fips1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.3.0-10.10 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.3.0-1004.4 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.3.0-1004.4 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.3.0-1004.5 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.3.0-1004.4 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.3.0-1004.4 - Upgrade
Upgrade
ubuntu/linux-raspito a version that resolves this vulnerability.Fixed in 7.3.0-1004.4 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.3.0-10.10.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.3.0-10.10.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-43.43 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1017.18 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1020.21 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1019.19 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1017.19 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1010.11 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1018.18 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1018.18 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-raspito a version that resolves this vulnerability.Fixed in 7.0.0-1023.23 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-43.43.1 - Compensating control
In packet_rcv_spkt(), guard restoration of the link-layer header with the dev_has_header() predicate before calling skb_push(), as packet_rcv() and tpacket_rcv() do.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel are affected when packet_rcv_spkt() processes traffic from a device that has no visible link-layer header. The description specifically identifies CAN SKBs as a case where the MAC-header field can remain at its 0xFFFF sentinel value.
What condition triggers the failure?
The failure occurs when packet_rcv_spkt() restores a link-layer header without first checking dev_has_header(). If skb->mac_header is the 0xFFFF sentinel, the computed push length becomes a large negative value and skb_push() reports an skb_under_panic() condition from softirq context.
Is there a mitigation if the kernel update cannot be applied immediately?
The provided information does not describe a configuration workaround. Mitigation would need to prevent the affected packet receive path from handling traffic on devices without visible link-layer headers, but no specific operational steps are supplied.