Description
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:
<IRQ>
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.
Published: 2026-10-23
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Kernel panic leading to denial of service
Action: Immediate patch
AI Analysis

Impact

In the kernel’s networking stack, the function packet_rcv_spkt restores the link-layer header by calling skb_push with a length computed from the difference between skb->data and skb->mac_header. When a network device has no visible link-layer header, the mac_header field remains at the sentinel value 0xFFFF. The calculation then yields a large negative number and skb_push triggers skb_under_panic, causing a kernel panic during a soft‑IRQ. An attacker with the CAP_NET_RAW capability can create a SOCK_PACKET socket and send frames to a device such as a CAN SLCAN interface; the kernel crash aborts the system, turning a single malicious packet into a denial‑of‑service event.

Affected Systems

This flaw exists in all Linux kernels that lack the patch introduced by commit d549699048b4. It is most readily triggered on devices that do not expose a link-layer header, notably CAN interfaces configured with CONFIG_CAN_SLCAN or similar drivers. The vulnerable code path is exercised when packets are received on such devices via SOCK_PACKET sockets. All distributions that ship an unpatched kernel are potentially affected; no specific version range is provided.

Risk and Exploitability

The vulnerability has no publicly available exploit and is not reported in CISA KEV. The EPSS score is < 1%, and the CVSS score is 5.5. The attack requires local privilege (CAP_NET_RAW) to open a SOCK_PACKET socket and send frames to a device such as a CAN SLCAN interface; the kernel crash aborts the system, turning a single malicious packet into a denial‑of‑service event.

Generated by OpenCVE AI on October 29, 2026 at 19:06 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that includes the patch that guards skb_push in packet_rcv_spkt.
  • If a kernel upgrade is not yet available, avoid using SOCK_PACKET sockets over CAN interfaces or unlink existing bindings until the patch is applied.
  • Continuously monitor system logs for skb_under_panic or kernel panic messages and plan for rapid reboot or recovery procedures.

Generated by OpenCVE AI on October 29, 2026 at 19:06 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 30 Oct 2026 13:00:00 +0000


Thu, 29 Oct 2026 15:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-457
CWE-680

Thu, 29 Oct 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-617
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate


Sat, 24 Oct 2026 00:45:00 +0000

Type Values Removed Values Added
First Time appeared Linux linux
Vendors & Products Linux linux

Fri, 23 Oct 2026 15:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-457
CWE-680

Fri, 23 Oct 2026 12:45:00 +0000

Type Values Removed Values Added
Description 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: <IRQ> 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.
Title net/packet: guard the ll header push in packet_rcv_spkt()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-30T12:41:06.206Z

Reserved: 2026-09-25T10:25:14.387Z

Link: CVE-2026-99033

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-23T13:17:26.443

Modified: 2026-10-30T13:21:40.243

Link: CVE-2026-99033

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-10-23T00:00:00Z

Links: CVE-2026-99033 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-29T19:15:08Z

Weaknesses