CVE-2026-23031: Linux Kernel gs_usb URB Memory Leak Flaw

CVE-2026-23031 Overview

A memory leak vulnerability has been discovered in the Linux kernel's GS_USB CAN (Controller Area Network) driver. The vulnerability exists in the gs_usb_receive_bulk_callback() function, where USB Request Blocks (URBs) used for USB-in transfers are not properly anchored after completion, leading to memory leaks when the device is closed.

The vulnerability stems from an incorrect assumption about URB lifecycle management. In gs_can_open(), URBs for USB-in transfers are allocated, added to the parent->rx_submitted anchor, and submitted. However, the USB framework unanchors URBs before calling the complete callback function. This means that once an in-URB has been completed, it is no longer anchored to parent->rx_submitted and consequently is not released when usb_kill_anchored_urbs() is called in gs_can_close().

Critical Impact

Repeated opening and closing of the GS_USB CAN device can lead to kernel memory exhaustion through leaked URB allocations, potentially causing system instability or denial of service.

Affected Products

• Linux Kernel (multiple versions with GS_USB driver)
• Systems using GS_USB-based CAN adapters
• Embedded systems with CAN bus connectivity via USB

Discovery Timeline

• 2026-01-31 - CVE CVE-2026-23031 published to NVD
• 2026-02-03 - Last updated in NVD database

Technical Details for CVE-2026-23031

Vulnerability Analysis

This memory leak vulnerability occurs within the Linux kernel's GS_USB driver, which provides support for GS_USB-compatible CAN (Controller Area Network) adapters. The driver manages USB Request Blocks (URBs) for handling incoming USB bulk transfers from the CAN device.

The core issue lies in the URB lifecycle management within the driver's receive callback mechanism. When gs_can_open() is called, the driver allocates URBs, anchors them to parent->rx_submitted, and submits them for USB-in transfers. The completion callback gs_usb_receive_bulk_callback() processes the received data and resubmits the URB for further transfers.

However, the USB framework's design causes URBs to be unanchored before the completion callback is invoked. This creates a window where completed URBs are no longer tracked by the anchor list. When gs_can_close() attempts to clean up by calling usb_kill_anchored_urbs(parent->rx_submitted), these unanchored URBs are missed, resulting in memory leaks.

Root Cause

The root cause is a failure to re-anchor URBs in the gs_usb_receive_bulk_callback() function after the USB framework automatically unanchors them prior to callback execution. The driver incorrectly assumed that URBs would remain anchored throughout their lifecycle, but the USB subsystem unanchors URBs before invoking completion callbacks to allow for flexible URB management.

Attack Vector

This vulnerability is primarily exploitable through local access to the system. An attacker with the ability to repeatedly open and close GS_USB CAN device interfaces could trigger the memory leak, gradually exhausting kernel memory. In systems where CAN devices are managed by automated processes or accessible to unprivileged users, this could lead to resource exhaustion and system instability.

The attack does not require special privileges beyond access to the CAN device, making it particularly concerning for systems where CAN interfaces are exposed to less privileged processes or services.

Detection Methods for CVE-2026-23031

Indicators of Compromise

• Gradual increase in kernel memory usage (slab allocations) over time on systems with GS_USB CAN devices
• Kernel memory exhaustion warnings in system logs after extended CAN device usage
• Unusual growth in URB-related memory allocations visible through /proc/slabinfo
• System instability or OOM (Out of Memory) killer activations on systems using GS_USB adapters

Detection Strategies

• Monitor kernel memory allocation patterns using tools like slabtop or /proc/meminfo for unexplained growth
• Implement kernel tracing on gs_can_open() and gs_can_close() calls to correlate with memory changes
• Review system logs for memory pressure warnings on systems running CAN applications
• Use kernel debugging tools to track URB allocation and deallocation patterns

Monitoring Recommendations

• Set up alerts for abnormal kernel memory growth on systems with GS_USB CAN devices
• Monitor /proc/slabinfo for increasing kmalloc-* or URB-related slab caches
• Implement periodic restarts of CAN services as a temporary mitigation measure
• Deploy memory monitoring dashboards for embedded systems using CAN interfaces

How to Mitigate CVE-2026-23031

Immediate Actions Required

• Update the Linux kernel to a patched version that includes the fix for gs_usb_receive_bulk_callback()
• Minimize frequent open/close cycles on GS_USB CAN devices until patched
• Monitor memory usage on affected systems and schedule periodic restarts if necessary
• Review and restrict access to CAN device interfaces to trusted processes only

Patch Information

The fix involves anchoring the URB in gs_usb_receive_bulk_callback() to the parent->rx_submitted anchor, ensuring proper cleanup when the device is closed. Multiple kernel commits address this vulnerability:

• Commit 08624b7206dd
• Commit 7352e1d5932a
• Commit 9f669a38ca70
• Commit f905bcfa971e

Apply the appropriate patch based on your kernel version by pulling from the stable kernel git repository.

Workarounds

• Limit access to GS_USB CAN device files to only essential processes and users
• Implement application-level connection pooling to reduce device open/close frequency
• Schedule periodic system restarts during maintenance windows to reclaim leaked memory
• Consider using alternative CAN adapters with different drivers until the patch is applied

# Check current kernel version and GS_USB driver status
uname -r
lsmod | grep gs_usb

# Monitor kernel memory usage for leak detection
watch -n 60 'cat /proc/meminfo | grep -E "MemFree|Slab|SUnreclaim"'

# Restrict CAN device access (temporary mitigation)
chmod 660 /dev/ttyACM*
chown root:canusers /dev/ttyACM*