CVE-2026-63990 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
bonding: refuse to enslave CAN devices
syzbot reported a kernel paging request crash in can_rx_unregister() inside net/can/af_can.c. The crash occurs because a virtual CAN device (vxcan) is being enslaved to a bonding master.
During the enslavement process, the bonding driver mutates and modifies the network device states to fit an Ethernet-like aggregation model. However, CAN devices operate on a completely different Layer 2 architecture, relying on the CAN mid-layer private data structure (can_ml_priv) instead of standard Ethernet structures. Since bonding does not initialize or maintain these CAN structures, subsequent operations on the half-enslaved interface (such as closing associated sockets via isotp_release) lead to a null-pointer dereference when accessing the CAN receiver lists.
Bonding CAN interfaces is architecturally invalid as CAN lacks MAC addresses, ARP capabilities, and standard Ethernet link-layer mechanisms. While generic loopback devices are blocked globally in net/core/dev.c, virtual CAN devices bypass this check because they do not carry the IFF_LOOPBACK flag, despite acting as local software-loopbacks.
Fix this by explicitly blocking network devices of type ARPHRD_CAN from being enslaved at the very beginning of bond_enslave(). This prevents illegal state mutations, eliminates the resulting KASAN crashes, and avoids potential memory leaks from incomplete socket cleanups.
As the CAN support has been added a long time after bonding the Fixes-tag points to the introduction of ARPHRD_CAN that would have needed a specific handling in bonding_main.c.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/19/2026
The vulnerability involves a critical architectural mismatch in the Linux kernel's bonding driver where it attempts to enslave CAN (Controller Area Network) devices despite their fundamentally incompatible network layer characteristics. This issue stems from the bonding driver's design assumption that all network interfaces operate within an Ethernet-like framework with standardized Layer 2 mechanisms including MAC addresses, ARP resolution, and link-layer management. The reported crash occurs in can_rx_unregister() function located at net/can/af_can.c where a kernel paging request failure manifests due to improper handling of virtual CAN devices (vxcan) being integrated into bonding aggregates. The technical flaw represents a violation of the fundamental network architecture principles where bonding driver modifications attempt to transform CAN device states to conform to Ethernet aggregation models while completely ignoring CAN's specialized Layer 2 implementation that relies on can_ml_priv private data structures rather than standard Ethernet constructs.
The operational impact of this vulnerability extends beyond simple crashes to encompass potential system instability and memory corruption scenarios. When a virtual CAN device is enslave to a bonding master, the bonding driver performs state mutations that are entirely inappropriate for CAN devices which lack essential Ethernet infrastructure such as MAC address management and ARP capabilities. Subsequent operations on these half-enslaved interfaces trigger null-pointer dereferences during socket cleanup operations like isotp_release because the bonding driver fails to initialize or maintain the required CAN-specific data structures. This creates a cascade of issues where incomplete socket cleanup procedures result in memory leaks and potential kernel memory corruption, making this vulnerability particularly dangerous in embedded systems and automotive applications where CAN networks are prevalent. The vulnerability operates under the ATT&CK framework as a privilege escalation vector through kernel memory corruption, specifically targeting the kernel's network subsystem with a weakness classified under CWE-476_NULL_Pointer_Dereference.
The fix implemented addresses this architectural incompatibility by introducing an explicit validation check at the beginning of the bond_enslave() function that prevents network devices of type ARPHRD_CAN from being processed for enslavement. This preventive measure eliminates the possibility of illegal state mutations that would otherwise occur when attempting to apply Ethernet-based bonding logic to CAN devices. The solution directly addresses the root cause by blocking CAN devices at the interface level before any problematic state modifications can occur, thereby preventing both KASAN crashes and memory leak scenarios associated with incomplete cleanup operations. This approach aligns with industry best practices for kernel security where architectural incompatibilities are resolved through early validation rather than attempting to retrofit incompatible systems. The fix specifically targets the introduction of ARPHRD_CAN support that predates proper bonding driver integration, ensuring that all CAN-based network interfaces are properly excluded from bonding operations while maintaining full compatibility with existing Ethernet-based aggregation functionality. This resolution prevents potential attackers from exploiting this vulnerability to gain unauthorized access or cause system instability through carefully crafted network device configurations that could otherwise lead to denial of service conditions and memory corruption within the kernel space.