CVE-2026-63928

What it actually does

This is a Linux kernel memory-corruption vulnerability in the USB serial omninet driver. A malicious USB device can advertise an unexpectedly small bulk-out endpoint maximum packet size; because the driver used a hardcoded transfer size without ensuring the allocated buffer was large enough, writes could overrun the allocated slab object. Successful exploitation can corrupt kernel heap memory and may lead to kernel crash, denial of service, or potentially kernel-mode code execution depending on kernel configuration, heap state, and available exploitation primitives.

Why it matters to the business

Systems that allow untrusted or attacker-controlled USB devices, USB passthrough, or exposed physical/console access could be crashed or potentially compromised at the kernel level. The practical risk is highest for workstations, kiosks, lab systems, embedded Linux devices, virtualization hosts using USB passthrough, and operational environments where USB devices are frequently attached. EPSS is currently low and there is no known KEV listing or reported ransomware use, but the impact is high where physical or device-level access is plausible because kernel compromise can bypass normal application-layer controls.

How an attack unfolds

An attacker needs the ability to present a malicious USB serial device to a vulnerable Linux system. The device identifies in a way that causes the omninet USB serial driver to bind, but reports a smaller bulk-out endpoint maximum packet size than the driver expects. When the driver allocates buffers based on the advertised endpoint characteristics and later performs transfers using the hardcoded larger size, kernel heap memory adjacent to the buffer can be overwritten. The immediate outcome may be a kernel panic or USB subsystem crash; with sufficient reliability work, heap grooming, and favorable kernel mitigations, the corruption could potentially be shaped into elevated kernel execution.

How to fix it

Update the Linux kernel to a version or vendor backport that includes the omninet USB serial buffer-size validation fix. If an immediate kernel update is not possible, reduce exposure by disabling or blacklisting the omninet driver if not required, restricting physical USB access, disabling USB ports where feasible, preventing USB passthrough from untrusted sources, and enforcing device-control policies that only allow approved USB hardware. On Linux systems, mitigation may include blacklisting the module with a modprobe configuration such as `blacklist omninet`, followed by initramfs regeneration where applicable and rebooting to ensure the driver cannot load.

How to confirm the fix worked

Confirm that the running kernel includes the vendor fix or is at a patched release level from the distribution or kernel supplier. Verify whether the omninet driver is present or loaded using module and sysfs checks such as `lsmod | grep omninet`, `modinfo omninet`, and inspection of `/sys/bus/usb-serial/drivers/`. If mitigation is used instead of patching, confirm the module is blacklisted, absent from initramfs if needed, and cannot be loaded after reboot. For exposure validation, review whether systems permit physical USB attachment, USB redirection, or virtualization USB passthrough from untrusted sources.

Typical attack path

1. Obtain physical access to the target system, compromise a USB peripheral, or gain control of a USB device passed through to a VM or host.
2. Present a crafted USB serial device that causes the Linux omninet driver to bind.
3. Advertise a bulk-out endpoint maximum packet size smaller than the driver’s hardcoded transfer size.
4. Trigger outbound USB serial activity through the driver so the oversized transfer corrupts adjacent kernel slab memory.
5. Use the corruption to crash the kernel or attempt further exploitation for kernel-level code execution.

How to detect it

Look for evidence that an unexpected USB serial device was attached and bound to the omninet driver, followed by kernel memory-corruption symptoms. Relevant sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, crash dumps, kdump/vmcore artifacts, audit logs for module loading, udev logs, EDR device-control telemetry, and hypervisor logs for USB passthrough or redirection. Investigate sequences where `omninet` or `usbserial` appears shortly before kernel warnings such as slab corruption, use-after-free-like reports, general protection faults, kernel oops, BUG/WARNING splats, or unexpected reboots. Because exploitation is device-driven, network IOCs are not expected; detection should focus on USB enumeration, driver binding, module loading, and kernel crash artifacts.

• omninet
• usbserial
• omninet.ko
• /sys/bus/usb-serial/drivers/omninet
• /lib/modules/*/kernel/drivers/usb/serial/omninet.ko
• /lib/modules/*/kernel/drivers/usb/serial/omninet.ko.xz
• /lib/modules/*/kernel/drivers/usb/serial/omninet.ko.zst
• USB Serial support registered for OmniNet
• usbserial: USB Serial support registered for OmniNet
• generic converter now attached to ttyUSB
• ttyUSB
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• general protection fault
• kernel BUG at
• slab-out-of-bounds
• KASAN: slab-out-of-bounds
• KASAN: use-after-free
• UBSAN: array-index-out-of-bounds
• Oops:
• Kernel panic - not syncing

What your security team should do

• Prioritize patching Linux systems where untrusted USB devices can be attached, including workstations, kiosks, shared consoles, lab equipment, embedded Linux appliances, and virtualization hosts using USB passthrough.
• Inventory systems with the omninet driver present or loaded and determine whether the driver is actually required.
• Disable or blacklist the omninet module on systems that do not need OmniNet USB serial support.
• Restrict USB device attachment using endpoint management, BIOS/UEFI controls, udev rules, hypervisor policy, or device-control tooling.
• Monitor kernel logs for suspicious USB enumeration events, unexpected omninet driver binding, USB serial device creation, kernel slab corruption warnings, oopses, or panics following USB activity.
• Treat crashes temporally associated with newly attached USB devices as potentially security-relevant and preserve kernel logs, crash dumps, and USB metadata for investigation.