CVE-2026-64334 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: digi_acceleport: fix hard lockup on disconnect
If submitting the OOB write urb fails persistently (e.g if the device is being disconnected) the driver would loop indefinitely with interrupts disabled.
Check for urb submission errors when sending OOB commands to avoid hanging if, for example, open(), set_termios() or close() races with a physical disconnect.
This is issue was flagged by Sashiko when reviewing an unrelated change to the driver.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability described represents a critical deadlock condition in the Linux kernel's USB serial driver subsystem, specifically within the digi_acceleport driver implementation. This flaw manifests as a hard lockup scenario that occurs when the driver attempts to handle out-of-band write operations during device disconnection events. The issue stems from inadequate error handling mechanisms that fail to properly detect and respond to urb (USB request block) submission failures, creating a pathological loop where the system becomes unresponsive with interrupts disabled.
The technical root cause lies in the driver's failure to implement proper error checking when submitting OOB commands through USB communication channels. When a device disconnects while operations are in progress, the urb submission process encounters errors that should trigger graceful degradation or immediate termination of the operation sequence. However, without appropriate error validation, the driver enters an infinite loop state where it continuously attempts to submit failed urb requests without yielding control back to the system scheduler. This behavior directly violates fundamental kernel design principles for resource management and prevents proper cleanup operations from executing.
The operational impact of this vulnerability extends beyond simple system hang conditions to potentially compromise entire system stability during USB device lifecycle events. When multiple threads or processes interact with serial devices through the digi_acceleport driver, race conditions between open(), set_termios(), and close() operations combined with physical disconnection events create a perfect storm for system lockups. The scenario becomes particularly dangerous when considering that USB devices may be disconnected while applications are actively communicating with them, leading to unpredictable behavior in embedded systems, industrial control environments, or any application requiring reliable serial communication.
This vulnerability aligns with CWE-835, which addresses infinite loops or iterations without proper termination conditions, and demonstrates a classic example of improper error handling in kernel space code. The issue also relates to ATT&CK technique T1490, which covers resource exhaustion through denial-of-service attacks, as the infinite loop effectively consumes system resources and prevents normal operation. The fix requires implementing robust error checking mechanisms that properly handle urb submission failures and ensure that disconnect scenarios trigger appropriate cleanup procedures rather than entering indefinite retry loops.
The resolution approach must address the specific race conditions inherent in concurrent USB device operations while maintaining compatibility with existing driver functionality. Proper implementation should include immediate termination of OOB command sequences upon detecting urb submission errors, along with appropriate state management to prevent inconsistent driver states during disconnection events. The fix should also consider implementing timeouts or retry limits for urb operations to prevent indefinite blocking scenarios while still allowing legitimate communication failures to be handled gracefully.
Industry best practices for USB driver development emphasize the importance of proper error handling and resource cleanup in interrupt contexts, where the kernel cannot afford to block indefinitely due to device communication issues. The digi_acceleport driver's vulnerability highlights the need for comprehensive testing scenarios that include concurrent access patterns and disconnection events, particularly when dealing with hardware interfaces that may experience unexpected loss of connection during active communication sessions. This type of fix demonstrates the critical importance of defensive programming practices in kernel space code where system stability depends on proper error recovery mechanisms rather than assuming perfect device behavior or consistent communication patterns.
The vulnerability serves as a reminder of the complex interaction between hardware and software in USB subsystems, where timing issues between device removal and ongoing I/O operations can create conditions that are difficult to reproduce but devastating when they occur. The fact that this issue was identified during unrelated code review underscores how careful attention to error handling patterns becomes essential when maintaining kernel drivers, as seemingly minor oversights in resource management can lead to system-wide stability problems. Proper implementation of the fix should include thorough testing with various USB device types and disconnection scenarios to ensure that the error handling logic works correctly across different hardware platforms and usage patterns.