CVE-2026-23298 Overview
A denial of service vulnerability exists in the Linux kernel's UCAN (USB CAN) driver that can cause the system to hang indefinitely. The vulnerability occurs in the ucan_read_bulk_callback() function when processing USB CAN messages with a zero-length message field. When a malformed or broken UCAN device sends a message with the length field set to 0, the driver enters an infinite loop, effectively hanging the entire system.
This vulnerability is similar to a previously fixed issue in the kvaser_usb driver (commit 0c73772cd2b8), indicating that broken devices with this behavior exist in the wild. The fix involves skipping zero-length messages and continuing to process subsequent messages in the buffer.
Critical Impact
A malformed USB CAN device can cause a complete system hang through an infinite loop in the kernel driver, resulting in denial of service that requires a hard reboot to recover.
Affected Products
- Linux kernel with UCAN driver enabled
- Systems using USB CAN interfaces with the ucan kernel module
- Embedded systems and industrial control systems utilizing CAN bus over USB
Discovery Timeline
- 2026-03-25 - CVE CVE-2026-23298 published to NVD
- 2026-03-25 - Last updated in NVD database
Technical Details for CVE-2026-23298
Vulnerability Analysis
The vulnerability resides in the UCAN driver's bulk message processing routine within the Linux kernel. The ucan_read_bulk_callback() function processes incoming USB bulk transfers containing CAN messages. Each message in the buffer has a length field that the driver uses to advance through the buffer.
When a malformed USB CAN device sends a message with a length value of zero, the driver's message parsing loop fails to advance its position in the buffer. Since the length is zero, the pointer to the next message remains unchanged, causing the driver to reprocess the same zero-length message indefinitely. This creates an infinite loop within the kernel context, consuming CPU resources and effectively freezing the system.
The root cause is a missing validation check for zero-length messages before using the length value to calculate the offset to the next message in the buffer.
Root Cause
The driver lacks proper input validation for the message length field received from USB CAN hardware. When iterating through messages in a bulk transfer buffer, the code assumes all message length values will be positive and non-zero. Without a check to skip or reject zero-length messages, the parsing loop cannot progress past such malformed entries.
This is a classic instance of improper input validation for data received from hardware interfaces. The fix implements a simple check: if the message length is 0, skip the message and continue processing the next one in the buffer.
Attack Vector
The attack requires physical access to connect a malicious or malfunctioning USB CAN device to the target system. Once connected, the device can send crafted USB bulk transfers containing messages with zero-length fields. When the kernel driver processes these malformed messages, it enters an infinite loop.
The attack surface includes:
- Industrial control systems using CAN bus interfaces
- Automotive diagnostics systems
- Embedded Linux systems with USB CAN adapters
- Any Linux system where an attacker can connect a USB device
This vulnerability can be triggered by either a deliberately malicious device or a malfunctioning legitimate device sending corrupted data.
Detection Methods for CVE-2026-23298
Indicators of Compromise
- System becomes completely unresponsive after USB CAN device connection
- High CPU utilization on the processor handling USB interrupts
- Kernel logs showing repeated UCAN driver activity before system freeze
- System requires hard reboot to recover after USB CAN device use
Detection Strategies
- Monitor for unexpected USB device connections, particularly CAN interface devices
- Implement kernel tracing on UCAN driver functions to detect abnormal loop patterns
- Use hardware watchdog timers to detect and recover from system hangs
- Deploy USB device whitelisting to prevent unauthorized CAN adapters
Monitoring Recommendations
- Configure system monitoring to alert on prolonged high CPU usage in kernel context
- Enable USB device auditing to log all CAN adapter connections
- Implement kernel soft lockup detection and configure appropriate timeout values
- Review kernel logs for ucan driver messages indicating potential issues
How to Mitigate CVE-2026-23298
Immediate Actions Required
- Update the Linux kernel to a patched version containing the fix
- Restrict physical access to USB ports on critical systems
- Blacklist the ucan module if USB CAN functionality is not required
- Implement USB device authorization policies to control which devices can connect
Patch Information
The Linux kernel maintainers have released patches to address this vulnerability across multiple stable kernel branches. The fix adds validation to check for zero-length messages in ucan_read_bulk_callback() and skips them to prevent the infinite loop condition.
Patches are available at the following kernel commits:
- Kernel Commit 13b646e
- Kernel Commit 1e446fd
- Kernel Commit aa9e0a7
- Kernel Commit ab6f075
- Kernel Commit bd85f21
- Kernel Commit c7bc62be
Workarounds
- Disable or blacklist the ucan kernel module if USB CAN functionality is not needed
- Implement strict USB device access controls limiting which devices can be connected
- Use hardware USB port blockers on systems in physically accessible locations
- Configure udev rules to prevent automatic loading of the UCAN driver for untrusted devices
# Configuration example
# Blacklist the ucan module to prevent automatic loading
echo "blacklist ucan" | sudo tee /etc/modprobe.d/blacklist-ucan.conf
# Unload the module if currently loaded
sudo modprobe -r ucan
# Verify module is not loaded
lsmod | grep ucan
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
