CVE-2026-64335

What it actually does

This is a denial-of-service flaw in the Linux kernel USB serial driver for Digi AccelePort devices. If a serial port is closed while its receive path is throttled, the driver may fail to resubmit the read USB request block when the port is reopened. As a result, the affected port stops receiving data until the USB device is physically reconnected or the driver is unbound and rebound. The issue affects availability of serial communications; it does not indicate memory corruption, privilege escalation, data theft, or remote code execution.

Why it matters to the business

Systems that rely on Digi AccelePort USB serial adapters can lose serial input unexpectedly, disrupting connected equipment, telemetry, industrial control interfaces, console access, point-of-sale peripherals, or other serial-dependent workflows. Recovery may require manual intervention such as reconnecting the device or rebinding the driver, which can cause operational downtime. The vulnerability is not listed in CISA KEV, has no known ransomware association, and currently has very low EPSS likelihood, so urgency is primarily driven by whether affected USB serial hardware is used in critical operations.

How an attack unfolds

An attacker would need the ability to interact with an affected Digi AccelePort USB serial port, typically through local access to a system where the device node is exposed or through software that can control the serial port state. The attacker causes or waits for the port receive path to become throttled, then closes the port while throttling is active. Due to the driver bug, reopening the port does not correctly clear the throttle state and resubmit the read URB. The device remains present, but receive traffic no longer flows through the port until the device is reconnected or the driver is rebound. There is no public indication of weaponized exploitation, named threat actor use, or remote exploitation at this time.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the digi_acceleport USB serial driver. If a vendor kernel is used, update to the distribution or appliance vendor release that backports the fix. No specific fixed package versions were provided in the input, so administrators should consult their Linux distribution security advisories and kernel changelogs for the Digi AccelePort USB serial throttle/read URB fix. Where immediate patching is not possible, reduce exposure by restricting access to affected /dev/ttyUSB* device nodes, limiting membership in groups that can access serial devices, disabling or blacklisting the digi_acceleport driver if the hardware is not required, and preparing an operational recovery procedure to rebind the driver or reconnect the device if receive traffic stops.

How to confirm the fix worked

Confirm whether the system loads or can load the digi_acceleport driver and whether Digi AccelePort USB serial hardware is in use. Validate remediation by checking that the installed kernel package includes the fix from the relevant vendor advisory or upstream stable kernel. Operationally, test the affected workflow by opening the serial port, exercising receive flow control/throttling behavior, closing and reopening the port, and confirming that receive data continues without requiring USB reconnection or driver rebind. Also verify that unauthorized users cannot access the serial device nodes and that unused driver modules are not loaded.

Typical attack path

1. Identify a Linux system using the Digi AccelePort USB serial driver.
2. Obtain local or application-level access that permits opening and closing the associated serial device node.
3. Trigger or induce a throttled receive state on the serial port.
4. Close the serial port while it is throttled.
5. Reopen or leave the service to reopen the port, causing receive traffic to remain broken because the read URB is not resubmitted.
6. Maintain denial of service until an operator reconnects the device, reloads/rebinds the driver, or applies a fixed kernel.

How to detect it

There are no known public indicators of malicious exploitation for this vulnerability, and successful abuse may look like an ordinary device or serial communications failure. To assess possible prior exploitation or exposure, review kernel logs, system journals, USB subsystem logs, and application logs for Digi AccelePort devices that stopped receiving data after serial port open/close events, throttle or flow-control conditions, or unexplained recovery after USB reconnects or driver rebinds. Useful sources include dmesg output, journald kernel messages, syslog, audit logs for access to /dev/ttyUSB* or related serial devices, service logs for applications that consume serial data, and command history or audit records showing manual driver unbind/rebind or module reload activity. Focus on repeated patterns where a port remains present but receive data stops until physical reconnection, module reload, or driver rebind. Because the issue does not produce a unique exploit artifact, detection should be treated as behavioral triage rather than definitive compromise identification.

What your security team should do

• Inventory Linux systems that use Digi AccelePort USB serial adapters or load the digi_acceleport kernel module.
• Prioritize patching for systems where serial connectivity supports critical operations, remote management, industrial equipment, or safety-sensitive workflows.
• Apply the vendor-supported kernel update that contains the driver fix; if no vendor fix is available yet, track the relevant distribution advisory until released.
• Restrict local access to serial device nodes and remove unnecessary users from groups that grant serial device access.
• If Digi AccelePort hardware is not required, disable or blacklist the digi_acceleport module to eliminate exposure.
• Document a temporary recovery procedure for operations teams, such as reconnecting the USB device or rebinding the driver, until all affected systems are patched.
• Monitor for repeated serial port failures, unexpected USB serial disconnect/rebind activity, and application errors indicating loss of serial receive data.