CVE-2026-63928: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-63928 Overview

CVE-2026-63928 is a memory corruption vulnerability in the Linux kernel's omninet USB serial driver. The driver allocates bulk-out buffers based on the endpoint's reported maximum packet size, then writes a hardcoded transfer size into them. A malicious USB device that advertises a smaller endpoint maximum packet size than the driver expects triggers slab corruption in kernel memory.

The flaw affects systems where an attacker can attach a crafted USB device to a Linux host running the omninet driver. The Linux kernel maintainers have merged fixes across multiple stable branches.

Critical Impact
A malicious USB device can trigger user-controlled slab corruption in the Linux kernel, enabling denial of service or potential local privilege escalation on affected hosts.

Affected Products

Linux kernel versions containing the drivers/usb/serial/omninet.c driver prior to the fix
Distributions shipping the mainline and long-term stable kernel branches referenced in the upstream commits
Any Linux-based system with the omninet USB serial module loaded and physical USB access

Discovery Timeline

2026-07-19 - CVE-2026-63928 published to the National Vulnerability Database
2026-07-19 - Last updated in NVD database

Technical Details for CVE-2026-63928

Vulnerability Analysis

The omninet USB serial driver in the Linux kernel handles ZyXEL Omni.net devices through the standard USB serial subsystem. During probe and write operations, the driver relies on the bulk-out endpoint's wMaxPacketSize value to size its transfer buffers. However, the driver writes a fixed hardcoded transfer length into these buffers when submitting URBs.

When a USB device reports an endpoint maximum packet size smaller than the hardcoded transfer size, the driver writes past the end of the allocated buffer. Because the buffer resides in the kernel slab allocator, the overflow corrupts adjacent slab objects. The out-of-bounds write is user-controlled in the sense that a malicious USB device chooses both the endpoint descriptor and the data written, giving an attacker influence over the corrupted memory contents.

Root Cause

The root cause is a mismatch between buffer allocation size and transfer size in the omninet driver. The fix ensures the bulk-out buffers are at least as large as the hardcoded transfer size, regardless of what the device reports for wMaxPacketSize. This is a classic heap-based out-of-bounds write [CWE-787] in kernel-mode code.

Attack Vector

Exploitation requires physical or logical USB access to the target host. An attacker connects a USB device that identifies as an Omni.net serial adapter but presents a bulk-out endpoint with a wMaxPacketSize smaller than the driver's hardcoded transfer size. When the kernel binds the omninet driver and a write occurs, the driver overflows the small slab-allocated buffer with attacker-influenced bytes. Attack scenarios include malicious USB peripherals, BadUSB-style implants, and virtualized environments that expose emulated USB hardware to guest kernels.

No public proof-of-concept code has been released. Readers should consult the upstream commits linked in the references section for the exact code paths modified by the fix.

Detection Methods for CVE-2026-63928

Indicators of Compromise

Kernel oops, panic, or KASAN reports referencing omninet_write, usb_serial_generic_write, or slab-out-of-bounds accesses in the USB serial subsystem
Unexpected loading of the omninet module on hosts that do not normally use ZyXEL Omni.net hardware
USB device connection events for vendors or product IDs matched by the omninet driver on systems that should not see such devices

Detection Strategies

Enable CONFIG_KASAN on test and canary systems to surface slab out-of-bounds writes originating from USB serial drivers
Audit dmesg and journalctl -k for USB enumeration anomalies, driver bind events, and slab corruption warnings
Monitor /sys/kernel/debug/usb/devices and udev events for unexpected serial adapter attachments in production environments

Monitoring Recommendations

Forward kernel logs to a centralized logging or SIEM platform and alert on slab corruption, KASAN, and omninet module load events
Track USB device connect and disconnect events with usbguard or auditd rules on servers, kiosks, and industrial control endpoints
Correlate driver bind events with user session and physical access data to identify unauthorized peripheral use

How to Mitigate CVE-2026-63928

Immediate Actions Required

Apply the upstream Linux kernel patches referenced by commits 0bda1893, 0fee0cca, 180996f0, 4e7d3218, 60df93d3, 9a386045, b496e25e, and f34cf292
Update to a distribution kernel package that incorporates the omninet buffer size fix
Blacklist the omninet module on hosts that do not require ZyXEL Omni.net serial adapters using /etc/modprobe.d/

Patch Information

The fix ensures bulk-out buffers in drivers/usb/serial/omninet.c are sized to at least the hardcoded transfer length, preventing the out-of-bounds write when a device reports a smaller wMaxPacketSize. Patches are available in the upstream kernel tree via the following commits: Kernel Git Commit 0bda1893, Kernel Git Commit 0fee0cca, Kernel Git Commit 180996f0, Kernel Git Commit 4e7d3218, Kernel Git Commit 60df93d3, Kernel Git Commit 9a386045, Kernel Git Commit b496e25e, and Kernel Git Commit f34cf292.

Workarounds

Blacklist the omninet kernel module on systems that do not need it to prevent driver binding
Deploy USB device authorization controls such as usbguard to allow only known-good peripherals
Restrict physical USB access to servers, laboratory, and production endpoints where the driver may be present

bash

# Blacklist the omninet driver on hosts that do not require it
echo 'blacklist omninet' | sudo tee /etc/modprobe.d/blacklist-omninet.conf
sudo rmmod omninet 2>/dev/null || true
sudo update-initramfs -u

# Enforce USB device authorization with usbguard
sudo apt-get install -y usbguard
sudo usbguard generate-policy > /etc/usbguard/rules.conf
sudo systemctl enable --now usbguard