CVE-2026-23082: Linux Kernel gs

CVE-2026-23082 Overview

A vulnerability has been identified in the Linux kernel's gs_usb CAN (Controller Area Network) driver that can lead to an infinite loop condition during device cleanup. The issue exists in the gs_usb_receive_bulk_callback() function where USB Request Blocks (URBs) are not properly unanchored when usb_submit_urb() fails, causing usb_kill_anchored_urbs() to loop indefinitely.

Critical Impact
This vulnerability can cause system hangs and denial of service when closing CAN USB devices due to an infinite loop in the kernel driver cleanup routine.

Affected Products

Linux kernel with gs_usb CAN driver enabled
Systems using Geschwister Schneider USB/CAN interfaces
Embedded systems utilizing CAN-over-USB functionality

Discovery Timeline

2026-02-04 - CVE-2026-23082 published to NVD
2026-02-05 - Last updated in NVD database

Technical Details for CVE-2026-23082

Vulnerability Analysis

This vulnerability stems from an incomplete fix introduced in commit 7352e1d5932a which addressed a URB memory leak in the gs_usb driver. The original fix re-anchored URBs before calling usb_submit_urb() in the gs_usb_receive_bulk_callback() function to prevent URB leaks during cleanup. However, this patch failed to account for scenarios where usb_submit_urb() returns an error.

When usb_submit_urb() fails, the URB remains in the anchored state. Subsequently, when gs_can_close() is called and attempts to clean up via usb_kill_anchored_urbs(&parent->rx_submitted), it enters an infinite loop because the anchor list never becomes empty—the failed URB cannot be killed since it was never successfully submitted.

Root Cause

The root cause is improper error handling in the USB callback function. When the URB is re-anchored before submission and the submission fails, the code path does not unanchor the URB, leaving it in a state where it blocks the cleanup routine from completing. This is a classic example of resource state management failure in kernel driver code.

Attack Vector

The attack vector for this vulnerability is local. An attacker with access to a system with gs_usb CAN hardware could trigger this condition by:

Initiating communication on the CAN interface
Causing conditions that lead to usb_submit_urb() failures (such as USB errors, resource exhaustion, or rapid connect/disconnect cycles)
Closing the CAN device, triggering the infinite loop in gs_can_close()

This can result in a denial of service condition where the affected process hangs indefinitely, potentially requiring a system reboot to recover.

The fix involves unanchoring the URB when usb_submit_urb() returns an error, and adding an informational message to aid in debugging such failures. The patched code ensures proper cleanup regardless of the submission result.

Detection Methods for CVE-2026-23082

Indicators of Compromise

System hangs or freezes when closing CAN USB devices
Processes stuck in uninterruptible sleep state (D state) related to gs_usb operations
Kernel log messages indicating URB submission failures in the gs_usb driver
High CPU usage in kernel threads handling USB device cleanup

Detection Strategies

Monitor for processes in D state associated with CAN device operations using ps aux | grep " D "
Implement kernel log monitoring for gs_usb error messages and URB-related warnings
Use dmesg analysis to detect patterns of USB submission failures on CAN interfaces
Deploy watchdog mechanisms to detect and alert on process hangs during device operations

Monitoring Recommendations

Configure alerting for kernel messages containing gs_usb and error keywords
Implement system monitoring for unexpectedly long device close operations
Monitor USB subsystem health metrics for CAN interface devices
Set up automated kernel log analysis for patterns indicating URB anchor issues

How to Mitigate CVE-2026-23082

Immediate Actions Required

Update the Linux kernel to a patched version containing the fix commits
If update is not immediately possible, avoid scenarios that may trigger USB submission errors
Monitor systems using gs_usb CAN interfaces for signs of the described hang behavior
Consider temporarily disabling gs_usb devices on critical systems until patched

Patch Information

The Linux kernel development team has released fixes for this vulnerability across multiple stable kernel branches. The following commits contain the patch:

Apply the appropriate patch based on your kernel version by updating to the latest stable kernel release for your distribution.

Workarounds

Avoid rapid open/close cycles on gs_usb CAN devices
Ensure stable USB connections to reduce submission errors
If the infinite loop occurs, a system reboot may be required to recover
Consider using alternative CAN interfaces if gs_usb devices cannot be patched immediately

bash

# Check if gs_usb module is loaded
lsmod | grep gs_usb

# Monitor kernel logs for gs_usb related errors
dmesg -w | grep -i "gs_usb\|can\|urb"

# Check for processes stuck in D state
ps aux | awk '$8 ~ /D/ {print}'

CVE-2026-23082: Linux Kernel gs_usb Driver DoS Flaw