CVE-2026-23082 in Linux
Summary
by MITRE • 02/04/2026
In the Linux kernel, the following vulnerability has been resolved:
can: gs_usb: gs_usb_receive_bulk_callback(): unanchor URL on usb_submit_urb() error
In commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak"), the URB was re-anchored before usb_submit_urb() in gs_usb_receive_bulk_callback() to prevent a leak of this URB during cleanup.
However, this patch did not take into account that usb_submit_urb() could fail. The URB remains anchored and usb_kill_anchored_urbs(&parent->rx_submitted) in gs_can_close() loops infinitely since the anchor list never becomes empty.
To fix the bug, unanchor the URB when an usb_submit_urb() error occurs, also print an info message.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 05/03/2026
The vulnerability described in CVE-2026-23082 resides within the Linux kernel's CAN (Controller Area Network) subsystem, specifically within the gs_usb driver implementation. This driver facilitates communication with USB-based CAN adapters, enabling automotive and industrial systems to interface with CAN networks. The flaw manifests in the gs_usb_receive_bulk_callback() function which handles asynchronous USB transfer completions. The issue stems from improper URB (USB Request Block) management during error conditions, creating a potential denial of service scenario that could compromise system stability.
The technical root cause involves a memory management inconsistency in the USB subsystem handling. When the gs_usb driver initializes USB transfers, it anchors URBs to prevent memory leaks during cleanup operations. However, the original patch addressing a previous memory leak inadvertently introduced this new vulnerability by not considering that usb_submit_urb() calls can fail. When submission fails, the URB remains anchored in the list but cannot be properly processed or removed, leading to a persistent anchor state that prevents proper cleanup operations.
The operational impact of this vulnerability is significant for systems relying on CAN communication through USB adapters. During normal operation, the driver maintains a list of submitted URBs to handle incoming data transfers. When usb_submit_urb() fails, the URB should be unanchored to allow proper cleanup, but the current implementation fails to do so. This results in gs_can_close() function entering an infinite loop as it attempts to kill all anchored URBs, but the list never becomes empty due to the unremoved anchor. The consequence is that the driver cannot be properly closed or reinitialized, effectively causing a denial of service condition that prevents further CAN communication.
This vulnerability aligns with CWE-404, which describes improper resource management leading to resource leaks, and also relates to CWE-691, concerning insufficient control of a resource through a long-lived reference. The issue demonstrates poor error handling in kernel-level USB subsystem code and represents a classic example of how seemingly benign fixes can introduce new security concerns. From an ATT&CK perspective, this vulnerability could be leveraged to create persistent denial of service conditions that impact system availability, potentially affecting automotive systems or industrial control networks where CAN communication is critical. The fix requires careful consideration of error paths in USB transfer management and proper URB anchoring/unanchoring practices to ensure that all resources can be properly released during both successful and failed operations.