Preface: In the automotive industry, SocketCAN is an open-source implementation of the Controller Area Network (CAN) protocol for Linux. It provides a way for different electronic control units (ECUs) in a vehicle to communicate with each other over the CAN bus. SocketCAN uses the Linux network stack and Berkeley socket API to implement CAN device drivers as network interfaces, allowing multiple applications to access a CAN device simultaneously.

Background: CAN Broadcast Manager (BCM) can send a sequence of CAN frames to an actuator. In fact, a key functionality of the BCM is to handle cyclic transmission of CAN frames, which is commonly used for tasks like sending a sequence of commands or data to control an actuator. Actuators receive signals and respond with specified actions, including changing the air-fuel ratio in the engine, tightening up the suspension, or even applying the brakes. They convert electrical information into mechanical action, directly influencing and controlling a variety of vehicle components.

Vulnerability details: In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking for bcm_op runtime updates The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The content and also the length of the sequence can be changed resp reduced at runtime where the ‘currframe’ counter is then set to zero. Although this appeared to be a safe operation the updates of ‘currframe’ can be triggered from user space and hrtimer context in bcm_can_tx().

Ref: Anderson Nascimento created a proof of concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh. At the rework of bcm_can_tx() the ‘count’ variable has been moved into the protected section as this variable can be modified from both contexts too.

Official announcement: Please see the link for details – https://www.tenable.com/cve/CVE-2025-38004