CVE-2026-64334

What it actually does

This flaw affects the Linux kernel USB serial driver for Digi AccelePort devices. When the driver attempts to submit an out-of-band USB request while the device is being disconnected, repeated submission failures can cause the driver to loop indefinitely with interrupts disabled. Because interrupts remain disabled during the loop, the affected CPU can hard lock, potentially destabilizing the system or requiring a reboot. The impact is denial of service rather than code execution or data theft.

Why it matters to the business

Systems that use the affected USB serial driver may become unresponsive if a Digi AccelePort USB serial device is disconnected at the wrong time or if an attacker can intentionally trigger disconnect races. This can interrupt workloads, serial-connected operational equipment, remote access paths, or embedded/industrial systems that depend on USB serial connectivity. The public exploitation likelihood is currently low based on EPSS and there is no known CISA KEV listing, but kernel-level denial-of-service flaws can still be operationally significant where physical or local device access is possible.

How an attack unfolds

An attacker needs a way to influence a system using the vulnerable Digi AccelePort USB serial driver, typically through physical access, control of a USB device, or local access that can repeatedly open, configure, or close the serial interface while the device is disconnected. The attacker triggers a race between serial-port operations such as open(), set_termios(), or close() and a USB disconnect event. During that race, the driver attempts to send an out-of-band command. If USB request submission fails persistently because the device is gone or disconnecting, the vulnerable driver can continue looping with interrupts disabled. The result is a hard lockup or severe system hang, causing denial of service until the machine recovers through watchdog action or is manually rebooted.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the upstream fix for the digi_acceleport USB serial driver. If no packaged fix is available yet, reduce exposure by removing or blacklisting the digi_acceleport module where Digi AccelePort USB serial devices are not required, limiting physical access to USB ports, disabling unused USB ports in firmware or policy, and avoiding untrusted USB serial hardware. For systems that must use these devices, prioritize maintenance windows for kernel updates and ensure watchdog/reboot policies are appropriate for service recovery.

How to confirm the fix worked

Confirm the running kernel contains the vendor fix by checking the installed kernel package version against the vendor security advisory or upstream stable kernel release notes. Verify whether the vulnerable driver is present or loaded using module and filesystem checks such as lsmod, modinfo, and inspection of drivers/usb/serial/digi_acceleport.ko where available. On systems where the device is not needed, validate that the module cannot be loaded after mitigation. Where safe and appropriate in a test environment only, exercise connect/disconnect and serial open/configure/close behavior to confirm the system no longer hangs.

Typical attack path

1. Identify a Linux system using the Digi AccelePort USB serial driver.
2. Obtain physical, local, or device-level ability to connect, disconnect, reset, or emulate the relevant USB serial device.
3. Repeatedly open, configure, or close the serial interface while triggering USB disconnect/reset behavior.
4. Cause out-of-band USB request submissions in the driver to fail persistently during the disconnect race.
5. Trigger a kernel hard lockup or system hang, resulting in denial of service.

How to detect it

Review kernel, system, and persistent journal logs for signs of a hard lockup, watchdog reset, or unexpected reboot occurring near USB serial device disconnect events. Relevant sources include dmesg output, /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k, crash dumps, kdump/vmcore artifacts, and hardware watchdog or management-controller event logs. Look for repeated USB disconnect/reset messages followed by NMI watchdog or hard lockup messages, especially where stack traces reference the digi_acceleport driver or USB serial core. Because exploitation primarily causes denial of service, there may be no attacker-created file or network artifact; absence of logs after the lockup is also consistent with this failure mode.

• digi_acceleport
• digi_acceleport.ko
• drivers/usb/serial/digi_acceleport.c
• usbserial
• watchdog: Watchdog detected hard LOCKUP
• NMI watchdog: Watchdog detected hard LOCKUP
• hard LOCKUP on cpu
• BUG: soft lockup
• usb disconnect
• USB disconnect
• unable to submit urb
• urb submission
• set_termios
• ttyUSB

What your security team should do

• Inventory Linux systems that use USB serial hardware, especially Digi AccelePort devices or the digi_acceleport kernel module.
• Patch affected kernels through vendor-supported updates as part of normal kernel security maintenance, prioritizing systems with physical exposure, kiosk/edge deployments, industrial/OT connectivity, or shared workspaces.
• If the driver is not required, blacklist or remove the digi_acceleport module and enforce USB device control policies.
• Restrict physical access to USB ports and prevent use of untrusted USB serial adapters.
• Monitor kernel logs for USB disconnect storms, hard lockup watchdog messages, and stack traces involving the digi_acceleport driver.
• Prepare operational recovery procedures for affected systems, including watchdog configuration and controlled reboot processes for remote or unattended devices.