CVE-2026-64333
High · 7.8CVSS
7.8
EPSS
0.2%
Published
Jul 25, 2026
CISA due date
—
Cloudanix analysis
A flaw in a Linux USB serial driver could let someone with local access crash a system or potentially gain full control of it.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Low
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Patch
- Effort
- Low
- Patch risk
- Low
What it actually does
This is a local Linux kernel memory-corruption flaw in the USB serial Digi AccelePort driver. The vulnerable driver mishandles timeout logic in digi_write_inb_command(): when a write URB is not available, it can still modify the transfer buffer and attempt to resubmit the URB instead of returning an error. For some control operations, including break control paths without a timeout, the broken jiffies comparison can cause immediate corruption under certain uptime and architecture conditions, particularly on 32-bit systems. A local user with permission to interact with the affected USB serial device can potentially corrupt kernel memory, leading to kernel crash, privilege escalation, or arbitrary kernel-code execution depending on exploitability and kernel hardening.
Why it matters to the business
Systems that use Digi AccelePort USB serial adapters with affected Linux kernels may be exposed to local privilege escalation or denial of service. The most likely operational impact is instability or crashes on hosts that rely on these adapters for serial connectivity, industrial control, network device management, point-of-sale peripherals, lab equipment, or embedded/edge systems. Because exploitation requires local privileges and access to the relevant device, broad internet-scale exploitation is unlikely; however, compromise of a low-privileged local account could potentially be turned into full system compromise on affected hosts. The issue is not currently listed in CISA KEV, has no known ransomware association, and has low EPSS, so remediation should be prioritized based on device usage and local-user exposure rather than public exploit pressure.
How an attack unfolds
An attacker first needs local access to a Linux system running a vulnerable kernel with the digi_acceleport USB serial driver loaded or loadable, and they must be able to open or issue control operations against the corresponding USB serial device. The attacker then triggers driver command paths that call digi_write_inb_command(), such as serial control operations that manipulate break or related device state. Due to incorrect timeout handling, the driver can update a URB transfer buffer while the URB is unavailable or otherwise not in the expected state, corrupting kernel memory. A simple exploit may only crash the kernel and cause a denial of service. A more advanced exploit would attempt to shape heap layout, repeatedly trigger the vulnerable path, and convert the corruption into controlled kernel memory modification to gain elevated privileges. No public exploit maturity is currently reported.
How to fix it
Apply a Linux kernel update that includes the upstream fix for the digi_acceleport driver write-buffer corruption. If fixed package versions are not provided by a distribution, use the relevant vendor advisory and install the latest stable kernel update for the affected release stream. Reboot into the updated kernel after installation; merely installing the package is not sufficient if the host continues running the vulnerable kernel. Where immediate patching is not possible, mitigate by disabling or preventing use of the digi_acceleport driver if Digi AccelePort USB serial hardware is not required, restricting local access to affected serial device nodes, removing untrusted users from groups with serial-device access, and applying kernel hardening features such as lockdown, module-signing enforcement, SELinux/AppArmor policy, and least-privilege device permissions. On systems that require these adapters, prioritize patching over mitigation because the vulnerable code is in kernel space.
How to confirm the fix worked
Confirm the running kernel, not just the installed kernel package, has been updated to a version containing the fix. Validate with standard platform tooling such as uname -r, package-manager kernel inventory, and vendor advisory mapping. Check whether the driver is present or loaded using lsmod, modinfo, or /sys/module/digi_acceleport. If the hardware is not needed, verify the module cannot be loaded and that any blacklist or module policy is effective after reboot. If the hardware is needed, verify affected serial device permissions are restricted to authorized users only. Review kernel logs after patching and normal device use to confirm there are no recurring USB serial, URB, KASAN, Oops, or panic messages associated with digi_acceleport.
Typical attack path
- Obtain local code execution or shell access as a low-privileged user on a Linux host.
- Identify that the Digi AccelePort USB serial driver is present, loaded, or can be triggered by an attached compatible USB serial device.
- Confirm the user can access the associated serial device node or otherwise invoke relevant tty/serial ioctls or control operations.
- Trigger command paths that call digi_write_inb_command(), such as break-control or related USB serial control operations.
- Cause write URB transfer-buffer corruption because the driver mishandles timeout or no-timeout conditions.
- Use the corruption to crash the kernel, or in a more advanced scenario, manipulate kernel memory to escalate privileges.
- Maintain access using the newly obtained privileges or disrupt operations by repeatedly causing kernel instability.
How to detect it
Detection should focus on signs of local probing or exploitation against hosts using the digi_acceleport driver. Review kernel logs, system journal, crash dumps, kdump/vmcore artifacts, audit logs, and endpoint telemetry for USB serial driver errors, kernel Oops or panic events, KASAN reports, general protection faults, use-after-free or slab corruption messages, and repeated interactions with Digi AccelePort serial device nodes. Correlate crashes or memory-corruption logs with local user sessions, commands that interact with /dev/ttyUSB* devices, unusual ioctl-heavy serial access, or newly attached USB serial hardware. Also check whether low-privileged users recently gained root privileges after kernel instability. The available public information does not provide a unique attacker file, process, network indicator, or exploit string; kernel crash artifacts involving digi_acceleport are the most useful forensic leads.
- digi_acceleport
- digi_write_inb_command
- /sys/module/digi_acceleport
- /dev/ttyUSB
- usbserial
- KASAN:
- BUG:
- Oops:
- general protection fault
- kernel panic
- slab corruption
- use-after-free
- URB
- write urb
What your security team should do
- Inventory Linux systems that use USB serial adapters, especially Digi AccelePort devices, embedded systems, operational technology jump hosts, device-management servers, and lab or industrial endpoints.
- Prioritize kernel updates on systems where untrusted or semi-trusted local users can log in, run workloads, or access serial devices.
- Reboot patched systems and verify they are running the fixed kernel version.
- If Digi AccelePort hardware is not required, disable or blacklist the digi_acceleport driver and enforce module-loading restrictions.
- Restrict access to /dev/ttyUSB* and related serial device nodes to explicitly authorized administrators or service accounts.
- Hunt for recent kernel crashes, Oops reports, KASAN findings, or unexplained reboots on systems where the digi_acceleport driver is loaded.
- Because this issue is not in KEV, has no known ransomware use, and has low EPSS, treat it as a targeted local-risk kernel issue rather than an urgent internet-facing emergency unless affected devices are widely deployed or exposed to untrusted local users.
The record
In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix write buffer corruption The digi_write_inb_command() is supposed to wait for the write urb to become available or return an error, but instead it updates the transfer buffer and tries to resubmit the urb on timeout. To make things worse, for commands like break control where no timeout is used, the driver would corrupt the urb immediately due to a broken jiffies comparison (on 32-bit machines this takes five minutes of uptime to trigger due to INITIAL_JIFFIES). Fix this by adding the missing return on timeout and waiting indefinitely when no timeout has been specified as intended. This issue was (sort of) flagged by Sashiko when reviewing an unrelated change to the driver.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|