CVE-2026-72114

The vulnerability in the CAN BCM (Broadcast Manager) subsystem isn't simply a missing validation check — it's the symptom of a structural failure where symmetric API operations developed asymmetric security properties. The bcm_tx_setup() function, which handles outbound CAN frame transmission, received Data Length Code (DLC) validation against CANFD_MAX_DLC (64) at some point in the kernel's evolution, likely during CAN FD support addition. The corresponding bcm_rx_setup() function with RX_RTR_FRAME — which handles automatic kernel responses to Remote Transmission Request (RTR) frames — did not receive the same validation. This created a window where the kernel could be induced to emit CAN frames violating the DLC constraint on the RX response path. This is the 'benign sender' pattern in action. Developers encounter DLC constraints during frame construction (the TX path) and correctly enforce them there. The assumption that the kernel's own generated responses will be well-formed goes unquestioned because those responses are rarely fuzzed — fuzzers generate malformed inbound frames, not malformed kernel responses to valid inbound frames. The RX_RTR_FRAME path sits in this gap: structurally present, functionally reachable, but outside the normal exercise and review surface area. What makes CAN specifically dangerous here is the broadcast nature of the bus. A malformed TX frame stays within the sender's system. A malformed RX response — generated by the kernel in reply to an RTR — goes to every device on the CAN segment. This can disrupt arbitration, trigger protocol errors in ECUs expecting well-formed frames, or be interpreted as a denial-of-service signal by bus monitors. The blast radius isn't contained; it's broadcast. For defenders: check your kernel versions for bcm_rx_setup() handling of RX_RTR_FRAME. If the system runs CAN or CAN FD and has user-accessible BCM sockets (via socketcan), this is reachable from local unprivileged contexts. Prioritize patching. Beyond this specific CVE, audit other symmetric CAN operations — TX/RX pairs, request/response handlers — for divergent validation. The pattern 'one side validated, the other not' is likely not isolated to BCM. Consider whether your CAN fuzzing harnesses treat kernel-generated responses as untrusted input; if they only fuzz inbound frames, you'll miss this entire class. The systematic fix isn't shared validation layers (which creates coupling fragility) but rather domain-invariant helpers that enforce CAN frame constraints universally, called by any code path that touches CAN frames.

Reviewed through automated stages and approved by a human before publication.