CVE-2026-63990

What it actually does

This Linux kernel flaw allows an invalid network-device state transition: a CAN-class network interface, such as a virtual CAN/vxcan device, can be enslaved to a bonding interface even though bonding expects Ethernet-like devices. Bonding mutates device state according to Ethernet aggregation assumptions, but CAN devices use CAN-specific mid-layer private structures. Subsequent socket or interface cleanup paths, including CAN receiver unregistration through can_rx_unregister() and ISO-TP socket release paths, can dereference missing or invalid CAN data structures, causing a kernel NULL pointer dereference, KASAN crash, kernel oops, possible memory cleanup issues, and service denial. The fix rejects devices of type ARPHRD_CAN at the start of bond_enslave().

Why it matters to the business

The primary risk is local or container-adjacent denial of service on Linux systems where an attacker can create or manipulate network interfaces with sufficient network administration privileges. Exploitation can crash the kernel or destabilize networking, potentially interrupting hosts, appliances, CI runners, virtualization nodes, industrial/automotive test systems using CAN tooling, or multi-tenant Linux platforms that expose network namespace capabilities. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported public exploit maturity in the provided data, and has a low EPSS score, so urgency is highest for systems that grant CAP_NET_ADMIN, allow unprivileged user namespaces, run CAN/vxcan tooling, or rely on high host availability.

How an attack unfolds

An attacker first needs the ability to perform privileged network administration operations, typically CAP_NET_ADMIN in a relevant network namespace or equivalent root-level access. They create or identify a bonding interface and a CAN-family interface such as vxcan. They then attempt to enslave the CAN interface to the bond, which the vulnerable kernel incorrectly permits or partially processes. Because the bonding driver applies Ethernet-style state changes to a CAN interface, the CAN mid-layer state is left inconsistent. When CAN sockets are closed, interfaces are torn down, or receiver registrations are cleaned up, kernel code reaches can_rx_unregister() or related release paths and accesses CAN receiver data that was not validly maintained for the bonded device. This results in a NULL pointer dereference or KASAN-detected crash, potentially taking down the host if kernel oops handling escalates to panic.

How to fix it

Apply the Linux kernel update from the appropriate distribution or kernel vendor that includes the bonding fix to reject ARPHRD_CAN devices in bond_enslave(). If no fixed package version is listed by the vendor yet, track the vendor advisory for this CVE and deploy the first stable kernel containing the patch. As interim mitigations, prevent untrusted users and workloads from obtaining CAP_NET_ADMIN, disable or restrict unprivileged user namespaces where operationally feasible, avoid exposing CAN/vxcan and bonding capabilities to containers, and blacklist or avoid loading unused CAN-related modules such as vxcan, can, can_raw, and can_isotp where they are not required. Operational controls should also prevent CAN interfaces from being added as bond slaves through automation, configuration management, or container runtime policies.

How to confirm the fix worked

Confirm the running kernel contains the vendor fix by checking installed kernel package changelogs, vendor advisory status, or source/backport notes for the change that rejects ARPHRD_CAN devices in bonding. Validate exposure by checking whether CAN interfaces exist and whether any bonding slaves are CAN-class devices; CAN interfaces usually report type 280 under /sys/class/net/<interface>/type. On a patched test system, attempting to enslave a vxcan/CAN device to a bond should fail cleanly and must not cause a kernel oops, KASAN report, or crash. Review kernel logs after validation for absence of can_rx_unregister(), isotp_release(), bonding, NULL pointer dereference, or KASAN crash messages related to the test.

Typical attack path

1. Obtain local code execution with CAP_NET_ADMIN, root privileges, or network namespace capabilities sufficient to create and modify network interfaces.
2. Create or use a bonding interface.
3. Create or use a CAN-family virtual interface, commonly vxcan.
4. Attempt to enslave the CAN interface to the bonding master using netlink or tooling such as ip link.
5. Trigger cleanup or release behavior by closing CAN/ISO-TP sockets, deleting interfaces, or tearing down the namespace.
6. Cause a kernel NULL pointer dereference/oops in CAN cleanup paths, potentially resulting in host denial of service.

How to detect it

Look for evidence of attempted CAN-to-bond interface manipulation followed by kernel instability. Useful sources include kernel logs from dmesg, journald, syslog, crash dumps, kdump/vmcore analysis, auditd command and netlink telemetry, EDR process telemetry, container runtime logs, and orchestration audit events that show privileged network operations. Search for creation of vxcan devices, bond interfaces, attempts to set a CAN/vxcan interface master to a bond, and subsequent kernel messages mentioning can_rx_unregister(), isotp_release(), bond_enslave(), NULL pointer dereference, KASAN, or kernel oops. In containerized environments, correlate these events with workloads granted CAP_NET_ADMIN, host networking, privileged mode, or user namespace creation. Existing exploitation indicators are likely to be behavioral rather than network-based because this is a local kernel misuse path, not a remote protocol exploit.

• can_rx_unregister
• isotp_release
• bond_enslave
• vxcan
• ARPHRD_CAN
• KASAN: null-ptr-deref
• KASAN: null-ptr-deref in can_rx_unregister
• BUG: kernel NULL pointer dereference
• Oops: 0000
• ip link add type vxcan
• ip link set vxcan
• ip link set dev vxcan
• master bond
• /sys/class/net/*/type:280
• can_isotp
• can_raw
• vxcan.ko

What your security team should do

• Patch Linux kernels on systems that permit local network administration, run containers with elevated networking capabilities, or use CAN/vxcan tooling.
• Inventory hosts where CAP_NET_ADMIN is granted to containers, CI jobs, automation, or non-administrative users, and reduce that privilege where possible.
• Disable unprivileged user namespaces or restrict user namespace creation on systems where it is not required.
• Block or alert on attempts to enslave CAN-class interfaces to bonding masters through netlink/audit monitoring or privileged command telemetry.
• Remove or blacklist unused CAN and ISO-TP kernel modules on general-purpose servers.
• Add regression tests or configuration checks to ensure interfaces with ARPHRD_CAN/type 280 are never configured as bond slaves.
• Monitor kernel logs for CAN/bonding-related oops, KASAN, or NULL pointer dereference events, especially on multi-tenant Linux systems.