CVE-2026-23362: Linux Kernel Privilege Escalation Flaw

CVE-2026-23362 Overview

A race condition vulnerability has been identified in the Linux kernel's CAN (Controller Area Network) Broadcast Manager (BCM) subsystem. The vulnerability exists in the bcm_rx_setup() function where a missing spin_lock_init() call can lead to uninitialized spinlock usage when handling RX_RTR_FRAME operations. This flaw was introduced as an incomplete fix following commit c2aba69d0c36, which added locking for bcm_op runtime updates but failed to account for the RX path when the RX_RTR_FRAME flag is set.

Critical Impact

Local attackers with access to CAN socket operations may exploit this race condition to cause kernel instability, potentially leading to denial of service or undefined behavior in systems utilizing CAN bus communication.

Affected Products

• Linux Kernel (versions with CAN BCM subsystem)
• Systems utilizing CAN bus communication with BCM socket operations
• Embedded Linux devices with CAN controller support

Discovery Timeline

• 2026-03-25 - CVE CVE-2026-23362 published to NVD
• 2026-03-25 - Last updated in NVD database

Technical Details for CVE-2026-23362

Vulnerability Analysis

The vulnerability resides in the Linux kernel's CAN BCM (Broadcast Manager) subsystem, specifically in the handling of receive operations with the RX_RTR_FRAME flag enabled. The BCM subsystem provides a socket interface for CAN communication that supports both transmission and reception of CAN frames with various filtering and timing capabilities.

The root cause stems from an incomplete implementation of locking mechanisms introduced in commit c2aba69d0c36. While that commit correctly added bcm_tx_lock initialization in bcm_tx_setup() for TX operations, it did not account for a specific edge case in RX operations. When an RX operation has the RX_RTR_FRAME flag set, the receive path calls bcm_can_tx() to send a predefined response frame upon receiving an RTR (Remote Transmission Request) frame. This function requires the bcm_tx_lock spinlock, which was never initialized for RX bcm_op structures allocated in bcm_rx_setup().

Using an uninitialized spinlock can result in undefined behavior, including potential deadlocks, data corruption, or kernel panics depending on the memory state at the time of access.

Root Cause

The root cause is the missing spin_lock_init() call when allocating bcm_op structures in bcm_rx_setup(). While the TX path properly initializes the bcm_tx_lock spinlock in bcm_tx_setup(), the RX path was not updated to account for scenarios where the RX operation may also transmit CAN frames (specifically when handling RTR frames with RX_RTR_FRAME flag).

Attack Vector

An attacker with local access to a system with CAN socket capabilities could potentially trigger this vulnerability by:

1. Creating a BCM socket and configuring an RX operation with the RX_RTR_FRAME flag set
2. Triggering an RTR frame reception that causes the kernel to call bcm_can_tx() with an uninitialized spinlock
3. Exploiting the race condition to cause kernel instability or denial of service

The vulnerability requires local access and CAN socket permissions, limiting the attack surface primarily to systems where CAN bus communication is actively used, such as automotive systems, industrial control systems, and embedded devices.

Detection Methods for CVE-2026-23362

Indicators of Compromise

• Kernel panic messages referencing bcm_can_tx or BCM socket operations
• System instability when CAN BCM receive operations with RX_RTR_FRAME flag are active
• Unexpected spinlock-related warnings in kernel logs during CAN operations
• Kernel oops or lockup events in systems actively using CAN bus communication

Detection Strategies

• Monitor kernel logs for spinlock-related warnings or errors in the CAN BCM subsystem
• Implement kernel instrumentation to detect uninitialized memory access in socket operations
• Deploy runtime analysis tools to identify race conditions in CAN subsystem operations
• Review system configurations for BCM socket usage with RX_RTR_FRAME flags

Monitoring Recommendations

• Enable kernel lock debugging (CONFIG_DEBUG_SPINLOCK, CONFIG_PROVE_LOCKING) in development environments
• Monitor for kernel oops messages containing bcm_rx_setup or bcm_can_tx function names
• Implement automated kernel log analysis for CAN-related error patterns

How to Mitigate CVE-2026-23362

Immediate Actions Required

• Update the Linux kernel to a patched version containing the fix
• If immediate patching is not possible, avoid using RX_RTR_FRAME flag in BCM socket operations
• Review CAN BCM socket configurations and disable unnecessary RTR response functionality
• Apply vendor-specific kernel patches as they become available

Patch Information

The fix adds the missing spin_lock_init() call when allocating bcm_op structures in bcm_rx_setup() to properly handle the RTR case. Multiple kernel stable branches have received patches:

Workarounds

• Disable the CAN BCM module (can_bcm) if not required for system operation
• Restrict access to CAN sockets using appropriate user permissions and capabilities
• Avoid configuring RX operations with the RX_RTR_FRAME flag until patches are applied
• Implement network segmentation to limit exposure of CAN-enabled systems

# Disable CAN BCM module if not required
sudo modprobe -r can_bcm

# Blacklist the module to prevent automatic loading
echo "blacklist can_bcm" | sudo tee /etc/modprobe.d/blacklist-can-bcm.conf

# Verify module is not loaded
lsmod | grep can_bcm