Live › vulnerability › CVE-2026-99066
Go to dashboardLinux CAN RX socket buffers are created without their MAC and network header offsets, so a SOCK_PACKET receiver can overflow a length calculation and hit a kernel BUG. The result is a full machine panic, which an attacker can trigger by sending CAN traffic to a host that has a SOCK_PACKET listener.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Hosts running a Linux kernel with CAN support where something opens a SOCK_PACKET socket on a CAN interface. Systems without CAN devices or without SOCK_PACKET listeners are unlikely to be exposed, but the sources do not say which kernel versions are affected.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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").
This page as .md · .json · in your agent: get_signal("CVE-2026-99066")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.