Cloudanix VulnDB

CVE-2026-99066

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux network handling can make the computer crash and restart when certain network packets arrive.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Improper skb header initialization in CAN receive path leaves mac_header at 0xFFFF, causing push length overflow and skb_under_panic in packet_rcv_spkt leading to kernel BUG and panic.

Why it matters to the business

Linux systems using CAN networking may suffer sudden kernel crashes and reboots when packet socket paths are exercised, resulting in unplanned downtime and loss of availability.

How an attack unfolds

An attacker transmits CAN frames received via alloc_can_skb family functions; when the skb reaches packet_rcv_spkt on a SOCK_PACKET socket the uninitialized header triggers the overflow and immediate kernel panic.

How to fix it

Apply the upstream kernel commit that restores skb_reset_mac_header, skb_reset_network_header and skb_reset_transport_header calls inside init_can_skb; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Inspect init_can_skb source for the three skb_reset_*_header calls; confirm the fix is present by source review or by testing that CAN RX skbs no longer produce mac_header 0xFFFF.

Typical attack path

  1. Transmit CAN frames to a vulnerable Linux system
  2. Ensure the skb is processed through packet_rcv_spkt
  3. Trigger integer overflow in skb push calculation
  4. Cause kernel BUG and full system panic

How to detect it

Search kernel logs and dmesg for BUG messages containing skb_under_panic, packet_rcv_spkt, or can skb header references; correlate with recent CAN interface activity.

What your security team should do

  • Prioritize kernel update within maintenance windows due to panic risk
  • Review CAN-enabled systems for exposure to packet socket usage
  • Test patched kernels in staging before broad deployment
  • Monitor kernel logs for skb_under_panic signatures

The record

In the Linux kernel, the following vulnerability has been resolved: can: dev: init_can_skb(): restore skb header initialization Commit 9f10374bb024 ("can: remove private CAN skb headroom infrastructure") removed the skb_reset_mac_header()/skb_reset_network_header()/ skb_reset_transport_header() calls from init_can_skb(). As a result, RX skbs from alloc_can_skb() and friends again carry mac_header = 0xFFFF. When such an skb reaches packet_rcv_spkt() (SOCK_PACKET), the push length calculation overflows and triggers skb_under_panic -> kernel BUG -> full machine panic. The same issue was originally reported in 2014 on linux-can and fixed by commit 969439016d2c ("can: add missing initialisations in CAN related skbuffs"). packet_rcv_spkt() itself has never been hardened: only packet_rcv() and tpacket_rcv() gained dev_has_header() checks in commit d549699048b4 ("net/packet: fix packet receive on L3 devices without visible hard header").

Affected packages

Ecosystem Package Introduced Fixed