Cloudanix VulnDB

CVE-2026-23362

Medium · 5.5

CVSS

5.5

EPSS

0.1%

Published

Mar 25, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A missing lock setup in the Linux kernel's CAN message handling could let certain network messages cause crashes on affected machines.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Missing spin_lock_init() for bcm_op in bcm_rx_setup() leaves the bcm_tx_lock uninitialized when RX_RTR_FRAME triggers bcm_can_tx(), enabling data races or undefined behavior on concurrent TX_SETUP updates.

Why it matters to the business

CAN-enabled embedded, automotive, or industrial systems may experience kernel instability or denial of service when handling remote transmission request frames, with low immediate exploitability but potential operational disruption in high-uptime environments.

How an attack unfolds

A local attacker with CAP_NET_ADMIN or direct access to a CAN interface sends RX_SETUP commands with RX_RTR_FRAME followed by RTR frames, exercising the uninitialized lock path during bcm_op runtime updates and triggering a race or crash.

How to fix it

Apply the upstream fix that adds spin_lock_init() inside bcm_rx_setup() when allocating bcm_op; rebuild and deploy the corrected kernel. Restrict unprivileged local access to CAN interfaces until patched.

How to confirm the fix worked

Inspect kernel source for spin_lock_init(&bcm_op->bcm_tx_lock) in bcm_rx_setup(); boot patched kernel, exercise RX_RTR_FRAME paths under concurrent load, and confirm absence of spinlock warnings or oops in dmesg.

Typical attack path

  1. Obtain local access or CAP_NET_ADMIN on a Linux system with CAN BCM enabled
  2. Configure a CAN interface and issue RX_SETUP ioctl with RX_RTR_FRAME flag
  3. Transmit RTR frames to invoke bcm_can_tx() through the rx bcm_op
  4. Trigger concurrent TX_SETUP operations to race on the uninitialized bcm_tx_lock

How to detect it

Review kernel logs for CAN BCM spinlock warnings, oops, or warnings referencing bcm_rx_setup or bcm_can_tx; correlate with CAN interface configuration changes in audit logs.

What your security team should do

  • Prioritize kernel updates containing the bcm locking fix on all CAN-using systems
  • Limit CAP_NET_ADMIN and direct CAN device access to trusted processes only
  • Monitor EPSS and KEV status for any future increase in exploit activity
  • Test CAN BCM functionality after patching to ensure RTR handling remains operational

The record

In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix locking for bcm_op runtime updates Commit c2aba69d0c36 ("can: bcm: add locking for bcm_op runtime updates") added a locking for some variables that can be modified at runtime when updating the sending bcm_op with a new TX_SETUP command in bcm_tx_setup(). Usually the RX_SETUP only handles and filters incoming traffic with one exception: When the RX_RTR_FRAME flag is set a predefined CAN frame is sent when a specific RTR frame is received. Therefore the rx bcm_op uses bcm_can_tx() which uses the bcm_tx_lock that was only initialized in bcm_tx_setup(). Add the missing spin_lock_init() when allocating the bcm_op in bcm_rx_setup() to handle the RTR case properly.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities