CVE-2026-99066 in Linux
Summary
by MITRE • 10/23/2026
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").
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability described involves a regression in the Linux kernel's Controller Area Network (CAN) subsystem, specifically within the initialization of socket buffer headers. The root cause lies in commit 9f10374bb024, which removed private CAN socket buffer headroom infrastructure to streamline code. This refactoring inadvertently eliminated critical calls to skb_reset_mac_header, skb_reset_network_header, and skb_reset_transport_header from the init_can_skb function. Consequently, receive socket buffers allocated via alloc_can_skb and related functions now carry a mac_header value of 0xFFFF instead of being properly initialized. This incorrect header state propagates through the network stack when these packets are processed by packet_rcv_spkt for SOCK_PACKET sockets.
The operational impact is severe, leading to a kernel panic that results in a full machine crash. When an improperly initialized socket buffer reaches the packet_rcv_spkt function, the logic responsible for calculating push lengths encounters invalid data due to the 0xFFFF mac_header value. This calculation overflows, triggering the skb_under_panic routine. The invocation of this panic handler causes the kernel to execute a BUG_ON check, which halts execution and crashes the system. This represents a denial-of-service condition that can be triggered by local or potentially remote actors depending on network configuration, effectively rendering the affected machine unusable until rebooted.
From a vulnerability classification perspective, this issue aligns with CWE-190 Integer Overflow or Wraparound, as the push length calculation fails due to invalid input data derived from uninitialized headers. It also relates to CWE-253 Incorrect Check of Function Return Value if viewed broadly in terms of state management failures, though more accurately it is a case of improper initialization leading to undefined behavior. In the context of MITRE ATT&CK, this vulnerability facilitates Local Privilege Escalation or Denial of Service via system crash, allowing an attacker with local access to disrupt service availability for all users on the host.
The historical context reveals that this flaw was previously addressed in 2014 by commit 969439016d2c which added missing initializations in CAN related skbuffs. The current regression occurred because subsequent refactoring efforts did not account for these necessary header resets. Furthermore, the packet_rcv_spkt function itself lacks hardening measures such as dev_has_header checks that were applied to packet_rcv and tpacket_rcv in commit d549699048b4. This inconsistency leaves a specific code path vulnerable while adjacent paths are protected against similar malformed input scenarios.
Mitigation strategies primarily involve applying the kernel patch that restores the skb header initialization calls within init_can_skb. System administrators should ensure their Linux kernels are updated to versions where this regression is resolved. For environments unable to immediately update, monitoring for CAN traffic anomalies and restricting access to SOCK_PACKET sockets can reduce exposure. Long-term remediation requires reviewing network stack refactoring changes against existing security hardening patterns to prevent similar regressions in other subsystems that rely on proper socket buffer state management.