CVE-2026-23058: Linux Kernel CAN Driver Memory Leak Flaw

CVE-2026-23058 Overview

A memory leak vulnerability has been identified in the Linux kernel's CAN (Controller Area Network) subsystem, specifically within the ems_usb driver. The vulnerability occurs in the ems_usb_read_bulk_callback() function where USB Request Blocks (URBs) allocated for USB-in transfers are not properly released, leading to memory exhaustion over time.

This vulnerability is similar to a previously fixed issue in the gs_usb driver (commit 7352e1d5932a) where the same URB memory leak pattern was identified and patched. The root cause stems from the USB framework's behavior of unanchoring URBs before invoking the completion callback, which prevents proper cleanup during device close operations.

Critical Impact

Systems using EMS CPC-USB CAN interfaces may experience memory exhaustion and potential denial of service conditions due to continuous URB memory leaks during normal USB operations.

Affected Products

• Linux kernel with ems_usb CAN driver enabled
• Systems using EMS CPC-USB or compatible CAN-to-USB interfaces
• Linux distributions with CAN subsystem support compiled into the kernel

Discovery Timeline

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

Technical Details for CVE-2026-23058

Vulnerability Analysis

The memory leak occurs due to a lifecycle management issue with USB Request Blocks (URBs) in the ems_usb driver. When the driver opens a device via ems_usb_open(), it allocates URBs for receiving USB bulk transfers, anchors them to the dev->rx_submitted anchor list, and submits them to the USB subsystem.

The critical flaw is in the completion callback handling. The USB framework unanchors each URB before calling the ems_usb_read_bulk_callback() completion function. This means that when URBs are processed and resubmitted in the callback, they are no longer attached to the anchor list. Subsequently, when ems_usb_close() is called, it invokes usb_kill_anchored_urbs(&dev->rx_submitted) expecting to free all URBs—but the unanchored URBs escape cleanup entirely.

Over time, this leads to progressive memory consumption as each completed URB that gets resubmitted remains unanchored and never gets freed. In systems with continuous CAN bus traffic, this can result in significant kernel memory exhaustion.

Root Cause

The root cause is the failure to re-anchor URBs in the completion callback ems_usb_read_bulk_callback() after the USB framework has unanchored them. The USB subsystem's design explicitly unanchors URBs before invoking completion handlers, which is expected behavior. However, the ems_usb driver did not account for this when implementing its URB resubmission logic.

The fix requires anchoring the URB back to the dev->rx_submitted anchor within the ems_usb_read_bulk_callback() function before resubmitting it. This ensures that all active URBs remain tracked and can be properly cleaned up when ems_usb_close() is called.

Attack Vector

This vulnerability is a memory leak that primarily poses a local denial of service risk. An attacker with local access to a system running the affected ems_usb driver could potentially:

1. Generate continuous CAN bus traffic to accelerate URB allocation
2. Force repeated open/close cycles on the CAN device interface
3. Exhaust available kernel memory over time, leading to system instability

The vulnerability requires local access and the presence of EMS USB-CAN hardware or emulated devices. The attack vector is considered local with no network exploitation path. The practical exploitability is limited as it requires specific hardware configurations and sustained traffic patterns to achieve meaningful impact.

Detection Methods for CVE-2026-23058

Indicators of Compromise

• Monitor for abnormal kernel memory growth when ems_usb driver is loaded and active
• Check for increasing slab allocations in USB-related memory pools using slabtop or /proc/slabinfo
• Watch for out-of-memory (OOM) conditions on systems with EMS CAN-USB interfaces

Detection Strategies

• Implement kernel memory monitoring to detect gradual memory consumption patterns associated with the ems_usb module
• Use kmemleak debugging tool to identify unreferenced URB memory allocations
• Review system logs for USB subsystem errors or memory allocation failures related to CAN devices

Monitoring Recommendations

• Enable kernel memory leak detection in development and testing environments
• Monitor /proc/meminfo for unusual kernel memory (Slab) growth during CAN interface operations
• Implement alerting for memory pressure events on systems utilizing CAN-over-USB interfaces

How to Mitigate CVE-2026-23058

Immediate Actions Required

• Update to a patched Linux kernel version containing the fix commits
• If immediate patching is not possible, consider unloading the ems_usb module when not in use
• Monitor affected systems for memory exhaustion symptoms and schedule regular reboots as a temporary measure
• Review CAN interface usage and disable unused EMS USB-CAN devices

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability. The fix properly anchors URBs in the ems_usb_read_bulk_callback() function before resubmission. The following kernel commits contain the fix:

• Kernel Git Commit 0ce73a0
• Kernel Git Commit 46a191f
• Kernel Git Commit 68c62b3
• Kernel Git Commit e9410fd

Multiple commits indicate the fix has been backported to various stable kernel branches. Verify your distribution's kernel packages include these patches.

Workarounds

• Unload the ems_usb kernel module using rmmod ems_usb when CAN functionality is not required
• Blacklist the ems_usb module by adding blacklist ems_usb to /etc/modprobe.d/blacklist.conf on systems not using EMS CAN hardware
• Implement scheduled system reboots to reclaim leaked memory until patching is complete
• Consider alternative CAN interfaces that use different kernel drivers as a temporary measure

# Temporarily unload the vulnerable ems_usb module
rmmod ems_usb

# Blacklist the module to prevent automatic loading
echo "blacklist ems_usb" >> /etc/modprobe.d/blacklist-ems_usb.conf

# Verify the module is not loaded
lsmod | grep ems_usb