CVE-2026-63990

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: refuse to enslave CAN devices<br /> <br /> syzbot reported a kernel paging request crash in<br /> can_rx_unregister() inside net/can/af_can.c. The crash occurs<br /> because a virtual CAN device (vxcan) is being enslaved to a<br /> bonding master.<br /> <br /> During the enslavement process, the bonding driver mutates<br /> and modifies the network device states to fit an Ethernet-like<br /> aggregation model. However, CAN devices operate on a completely<br /> different Layer 2 architecture, relying on the CAN mid-layer<br /> private data structure (can_ml_priv) instead of standard<br /> Ethernet structures. Since bonding does not initialize or<br /> maintain these CAN structures, subsequent operations on the<br /> half-enslaved interface (such as closing associated sockets<br /> via isotp_release) lead to a null-pointer dereference when<br /> accessing the CAN receiver lists.<br /> <br /> Bonding CAN interfaces is architecturally invalid as CAN lacks<br /> MAC addresses, ARP capabilities, and standard Ethernet<br /> link-layer mechanisms. While generic loopback devices are<br /> blocked globally in net/core/dev.c, virtual CAN devices<br /> bypass this check because they do not carry the IFF_LOOPBACK<br /> flag, despite acting as local software-loopbacks.<br /> <br /> Fix this by explicitly blocking network devices of type<br /> ARPHRD_CAN from being enslaved at the very beginning of<br /> bond_enslave(). This prevents illegal state mutations,<br /> eliminates the resulting KASAN crashes, and avoids potential<br /> memory leaks from incomplete socket cleanups.<br /> <br /> As the CAN support has been added a long time after bonding<br /> the Fixes-tag points to the introduction of ARPHRD_CAN that<br /> would have needed a specific handling in bonding_main.c.