CVE-2026-63901

What it actually does

This is a Linux kernel memory-corruption flaw in the USB serial digi_acceleport driver. A malicious USB device can advertise unexpectedly small bulk-out endpoint buffers; without proper size validation, the driver may perform out-of-bounds memory accesses and corrupt kernel slab memory. The most likely technical outcomes are kernel crash, denial of service, or device-driver instability, with potential for kernel-level code execution if an attacker can reliably shape memory and exploit the corruption. Exploitation requires the vulnerable driver to bind to a crafted USB device, including a physical USB device or a USB device presented through USB-over-IP or similar redirection mechanisms.

Why it matters to the business

Affected Linux systems that allow untrusted USB peripherals could be crashed or potentially compromised at the kernel level by a malicious device. The operational risk is highest for workstations, kiosks, labs, industrial systems, jump boxes, or servers where USB access is permitted or where USB-over-IP is enabled. This issue is not currently listed as known exploited and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, the impact can still be severe in environments exposed to malicious or uncontrolled USB hardware.

How an attack unfolds

An attacker prepares a USB device that presents descriptors matching the Digi AccelePort USB serial driver while reporting bulk-out endpoint buffer sizes smaller than the driver expects. When the device is connected to a vulnerable Linux system, the kernel USB subsystem enumerates it and loads or binds the digi_acceleport driver. During driver initialization or subsequent I/O handling, the driver uses the undersized endpoint information and performs memory operations beyond the allocated buffer boundary, corrupting kernel heap/slab memory. Depending on system hardening, timing, and memory layout, this may result in a kernel oops, panic, device-driver crash, or potentially controlled kernel memory corruption. The attack is most plausible through physical access, malicious peripherals, compromised peripheral supply chains, or USB redirection paths such as USB/IP.

How to fix it

Apply a Linux kernel update from the operating-system or appliance vendor that includes the upstream fix adding bulk-out buffer size sanity checks to the digi_acceleport USB serial driver. If an updated kernel is not immediately available, reduce exposure by disabling or blacklisting the digi_acceleport module where Digi AccelePort USB serial hardware is not required, restricting physical USB access, enforcing USB device allowlisting, disabling USB-over-IP/redirection where unnecessary, and preventing automatic loading of unused USB serial drivers. Because no fixed package versions were provided in the input, use the vendor advisory or kernel changelog to identify the first fixed kernel for each distribution or product line.

How to confirm the fix worked

Confirm that the running kernel package includes the fix for the digi_acceleport bulk-out buffer size validation issue. Validate by checking distribution advisories, kernel changelogs, or source/backport notes for changes in drivers/usb/serial/digi_acceleport.c that add sanity checks for bulk-out buffer sizes. Confirm exposure by checking whether the driver is present or loaded using commands such as lsmod, modinfo digi_acceleport, and kernel configuration checks for CONFIG_USB_SERIAL_DIGI_ACCELEPORT. After remediation, reboot into the fixed kernel, verify the active kernel version with uname -a, verify that the old vulnerable kernel is not the boot default, and confirm that any intended module blacklist or USB device-control policy is active.

Typical attack path

1. Obtain physical, supply-chain, or USB-redirection access to a Linux system that permits USB serial devices.
2. Present a crafted USB device whose descriptors cause the kernel to bind the digi_acceleport USB serial driver.
3. Advertise bulk-out endpoint properties with buffers smaller than the driver safely handles on vulnerable kernels.
4. Trigger driver initialization or serial I/O paths that write or read beyond the allocated endpoint buffer.
5. Cause kernel slab corruption, leading to a crash, denial of service, or possible kernel-level compromise.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, system journals, crash dumps, and endpoint telemetry for suspicious USB device enumeration followed by kernel memory-corruption symptoms. Focus on events where the digi_acceleport driver was loaded or bound shortly before a kernel oops, panic, KASAN report, slab corruption warning, or unexpected reboot. Useful log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, system crash repositories, kdump/vmcore data, EDR device-control logs, USB device inventory logs, hypervisor USB passthrough logs, and USB/IP service logs. Look for newly attached or unfamiliar USB serial devices, repeated connect/disconnect activity, automatic modprobe activity for digi_acceleport, and crash signatures involving USB serial handling. There are no known public exploit artifacts or network indicators from the provided information, and exploitation may leave only local kernel and device-enumeration evidence.

• digi_acceleport
• digi_acceleport.ko
• drivers/usb/serial/digi_acceleport.c
• CONFIG_USB_SERIAL_DIGI_ACCELEPORT
• modprobe digi_acceleport
• usbserial: USB Serial support registered
• USB Serial support registered for Digi
• KASAN: slab-out-of-bounds
• BUG: KASAN
• slab corruption
• kernel BUG at
• Oops:
• Kernel panic
• general protection fault
• usbip attach
• usbipd

What your security team should do

• Prioritize patching systems where untrusted users can connect USB devices, including workstations, kiosks, lab systems, shared servers, and operational technology endpoints.
• Inventory Linux hosts for presence or loading of the digi_acceleport USB serial driver and prioritize remediation where the driver is enabled.
• If Digi AccelePort USB serial support is not business-critical, blacklist or remove the module until all systems are running a fixed kernel.
• Restrict physical USB access and enforce USB device allowlisting for high-value systems.
• Review and disable USB-over-IP, hypervisor USB passthrough, or remote peripheral redirection features unless explicitly required.
• Monitor kernel logs for USB enumeration events followed by KASAN, slab corruption, oops, or panic messages referencing USB serial activity.
• Treat unexpected kernel crashes shortly after USB insertion as suspicious and preserve kernel logs, crash dumps, and details of attached USB devices for investigation.