CVE-2026-63990: Linux Kernel Privilege Escalation Flaw

CVE-2026-63990 Overview

CVE-2026-63990 is a Linux kernel vulnerability in the bonding driver that allows a null pointer dereference when a Controller Area Network (CAN) device is enslaved to a bonding master. The flaw was surfaced by syzbot, which triggered a kernel paging request crash in can_rx_unregister() inside net/can/af_can.c. The bonding driver mutates network device state to fit an Ethernet aggregation model, but CAN devices use the can_ml_priv mid-layer structure rather than standard Ethernet structures. Enslaving a virtual CAN (vxcan) interface leaves the device half-initialized, and subsequent socket cleanup paths such as isotp_release dereference uninitialized CAN receiver lists.

Critical Impact
A local unprivileged user with CAP_NET_ADMIN in a namespace can crash the kernel by enslaving a virtual CAN device to a bonding master, producing a null-pointer dereference and denial of service.

Affected Products

Linux kernel — bonding driver (drivers/net/bonding/bond_main.c)
Virtual CAN (vxcan) and other ARPHRD_CAN-type network devices
Stable kernel branches receiving the referenced backport commits

Discovery Timeline

2026-07-19 - CVE-2026-63990 published to the National Vulnerability Database
2026-07-19 - Last updated in NVD database

Technical Details for CVE-2026-63990

Vulnerability Analysis

The bonding driver assumes its slave devices behave like Ethernet interfaces. It reconfigures MAC addresses, ARP behavior, and link-layer state during bond_enslave(). CAN devices operate at a fundamentally different Layer 2. They lack MAC addresses, ARP, and Ethernet link mechanisms, and they store per-device receive state in can_ml_priv rather than in standard net_device fields.

When a CAN interface is enslaved, the bonding driver mutates state that the CAN subsystem never expects to change and never touches the structures the CAN stack actually relies on. The device is left in an inconsistent, partially enslaved condition. Later operations that walk CAN receiver lists — such as closing an ISO-TP socket through isotp_release() — reach a null pointer and trigger a KASAN-reported kernel paging fault in can_rx_unregister().

A related check in net/core/dev.c blocks generic loopback devices from being enslaved, but virtual CAN devices bypass it because they do not carry the IFF_LOOPBACK flag even though they act as software loopbacks. The fix explicitly rejects any device of type ARPHRD_CAN at the top of bond_enslave(), preventing the illegal state mutation before it starts.

Root Cause

The root cause is missing type validation in bond_enslave(). The bonding driver did not verify that the candidate slave uses an Ethernet-compatible link layer. Any ARPHRD_CAN device was allowed through, producing partially initialized state and a subsequent null pointer dereference on socket teardown.

Attack Vector

Exploitation requires local access with the ability to configure networking. An actor with CAP_NET_ADMIN — including inside an unprivileged user namespace on kernels where that is permitted — creates a vxcan pair, adds it to a bonding master with ip link set <can> master bond0, opens and closes a CAN socket on the interface, and triggers the crash. The result is a kernel oops and denial of service on the affected host.

No verified public exploit code is associated with CVE-2026-63990. See the Linux kernel commit for the authoritative fix.

Detection Methods for CVE-2026-63990

Indicators of Compromise

Kernel oops or KASAN reports referencing can_rx_unregister or isotp_release in net/can/af_can.c
dmesg entries showing a bonding master accepting a slave of type ARPHRD_CAN (ARP type 280)
Unexpected creation of vxcan or vcan interfaces followed by bond enslavement events on hosts that do not use CAN in production

Detection Strategies

Audit kernel logs for paging-request faults with call stacks in can_rx_unregister, bond_enslave, or isotp_release
Monitor netlinkRTM_NEWLINK events that set IFLA_MASTER on interfaces with ifi_type == ARPHRD_CAN
Correlate CAP_NET_ADMIN use inside user namespaces with subsequent bonding configuration changes

Monitoring Recommendations

Ingest /dev/kmsg and journald into a central log store and alert on kernel oops signatures involving CAN or bonding symbols
Track ip link and nmcli activity via auditd rules on the ioctl and netlink syscalls used to build bonds
Baseline which hosts legitimately load the can, vcan, vxcan, and bonding modules; alert on unexpected module loads

How to Mitigate CVE-2026-63990

Immediate Actions Required

Apply the upstream stable kernel update that includes the bond_enslave()ARPHRD_CAN rejection fix
Restrict CAP_NET_ADMIN in user namespaces on multi-tenant hosts where CAN and bonding are not required
Blacklist unused CAN modules (can, vcan, vxcan, can_isotp) on servers that have no CAN workload

Patch Information

The fix rejects ARPHRD_CAN devices at the start of bond_enslave() and has been backported across stable branches. Verified fix commits include 02f1c87ded33, 41e8478c4cd8, 563090e5d450, 69b78b5f3033, 8ba68464e478, 9ea8a648d912, and f4d78a81f57d. Rebuild or upgrade to a distribution kernel that contains one of these commits.

Workarounds

Prevent loading of the bonding module on hosts that also expose CAN interfaces, using install bonding /bin/true in /etc/modprobe.d/
Disable creation of vxcan and vcan pairs in untrusted namespaces by blacklisting the modules
Enforce SELinux or AppArmor policies that deny non-root workloads the ability to configure bonding masters

bash

# Configuration example: disable unused CAN and bonding modules until the kernel is patched
cat <<'EOF' | sudo tee /etc/modprobe.d/disable-can-bond.conf
blacklist vcan
blacklist vxcan
blacklist can_isotp
install bonding /bin/true
EOF
sudo depmod -a