CVE-2026-63957

What it actually does

This is a Linux kernel memory-corruption flaw in the USB serial safe_serial driver. A malicious USB serial device can advertise an abnormally small bulk-out endpoint size; before the fix, the driver could allocate or use a buffer smaller than the minimum size expected by the driver’s “safe” mode logic, allowing attacker-controlled slab memory corruption in kernel space. The most likely outcome is a kernel crash or denial of service, but because the corruption occurs in kernel memory, reliable exploitation could potentially lead to kernel-level code execution depending on kernel configuration, allocator state, hardening features, and attacker control over USB interaction timing.

Why it matters to the business

Systems that allow untrusted USB devices, USB passthrough, or field-attached hardware could be crashed or potentially compromised by a malicious or tampered USB serial device. The risk is most relevant to laptops, workstations, kiosks, industrial systems, lab equipment, embedded Linux devices, and virtualization hosts that expose USB devices to guests. Current public exploitation indicators are low: EPSS is 0.00211, it is not listed in CISA KEV, it is not flagged for ransomware use, and exploit maturity is reported as none; however, the impact can be severe where physical or supply-chain USB access is realistic.

How an attack unfolds

An attacker prepares a malicious USB device that presents itself as a USB serial device compatible with the Linux safe_serial driver. The device reports a bulk-out endpoint size smaller than the driver safely expects. When the vulnerable Linux system enumerates the device and binds it to the safe_serial driver, subsequent driver operations in safe mode use assumptions that require at least an eight-byte bulk-out buffer. The malformed descriptor can cause user-controlled corruption of kernel slab memory. Depending on timing, kernel heap layout, and enabled mitigations, exploitation may result in a system crash, kernel panic, or potentially arbitrary code execution in kernel context. Practical exploitation generally requires physical access, malicious peripheral insertion, compromised peripheral firmware, or USB passthrough from an attacker-controlled device into a vulnerable host or guest.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the safe_serial fix requiring the bulk-out buffer size to be at least eight bytes. No exact fixed package versions were provided in the input, so use vendor advisories and distribution security trackers to identify the corrected kernel package for each platform. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the safe_serial driver if it is not required, restricting untrusted USB device attachment, enforcing USB device allowlisting with tools such as USBGuard, disabling USB passthrough for untrusted devices, and limiting physical access to systems that accept USB peripherals. If the driver is built into the kernel rather than loadable, mitigation may require boot-time device authorization controls, USB controller restrictions, or a patched kernel.

How to confirm the fix worked

Confirm that systems are running a kernel package containing the upstream safe_serial fix. On Linux systems, check the active kernel with `uname -r`, verify installed kernel package versions against vendor security advisories, and confirm whether the safe_serial module is present or loaded using `lsmod`, `modinfo safe_serial`, or distribution-specific package inspection. If mitigating by disabling the driver, confirm that the module cannot be loaded and that USB serial devices do not bind to safe_serial. For source-based kernels, verify the patched logic ensures the bulk-out buffer size is at least eight bytes before safe mode operations. Exposure validation should include reviewing whether endpoints permit untrusted USB devices, whether USB passthrough is enabled, and whether USB device authorization policies are enforced.

Typical attack path

1. Obtain physical access to the target system, compromise a peripheral supply chain, or gain the ability to present a USB device through passthrough or emulation.
2. Configure a malicious USB serial device to match identifiers handled by the Linux safe_serial driver.
3. Advertise a bulk-out endpoint with a size smaller than eight bytes.
4. Wait for the vulnerable Linux kernel to enumerate the device and bind it to the safe_serial driver.
5. Trigger safe_serial communication paths, causing the driver to operate on an undersized buffer.
6. Exploit the resulting kernel slab corruption to crash the system or attempt more advanced kernel-level exploitation.

How to detect it

Detection of prior exploitation is difficult because the attack is hardware-driven and may leave only kernel and USB enumeration artifacts. Review kernel logs, persistent journal entries, audit records, crash dumps, and endpoint management telemetry for USB serial device attachment events immediately followed by kernel oops, panic, slab corruption, KASAN, or unexpected reboot messages. Focus on systems where safe_serial was loaded or where USB serial devices were attached shortly before instability. Useful log sources include `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, `journalctl -k`, `dmesg` output captured by monitoring tools, kernel crash dumps under `/var/crash`, and EDR telemetry that records device insertions or kernel module loads. Investigate unfamiliar USB devices, devices with unusual descriptors, repeated connect/disconnect cycles, unexpected binding to safe_serial, or crashes occurring during USB enumeration. Because there are no public reports of active exploitation, no ransomware linkage, and no KEV listing, detection should be anomaly-based rather than signature-only.

• safe_serial
• safe_serial.ko
• drivers/usb/serial/safe_serial.ko
• /lib/modules/*/kernel/drivers/usb/serial/safe_serial.ko
• modprobe safe_serial
• insmod safe_serial
• usbserial: USB Serial support registered for safe
• KASAN: slab-out-of-bounds
• BUG: KASAN
• kernel BUG at
• general protection fault
• unable to handle kernel paging request
• Oops:
• Kernel panic - not syncing
• USB disconnect
• new full-speed USB device
• new high-speed USB device
• usbserial

What your security team should do

• Prioritize patching Linux systems that permit physical USB access, operate in public or semi-trusted locations, use USB serial devices, or support USB passthrough.
• Inventory systems where the safe_serial driver is present, loaded, built into the kernel, or required for business operations.
• If safe_serial is not needed, blacklist or disable the driver and confirm the mitigation survives reboot.
• Restrict untrusted USB devices using physical controls, BIOS or firmware settings, USBGuard-style allowlisting, and virtualization passthrough policies.
• Monitor kernel logs for suspicious USB enumeration followed by kernel memory corruption, KASAN reports, oops events, or unexplained reboots.
• Treat crashes following newly attached USB serial devices as potentially security-relevant and preserve kernel logs, crash dumps, and device metadata.
• Track vendor advisories because exact fixed versions vary by Linux distribution and kernel packaging stream.