CVE-2026-63902

What it actually does

This is a Linux kernel memory-safety flaw in the USB serial Cypress M8 driver. The driver parses interrupt-in USB packets using a format-specific header length, but before the fix it could read header bytes even when a USB transfer completed with a shorter-than-expected packet. A malformed or malicious USB device, or an attacker able to influence USB device traffic through USB passthrough or USB/IP-style exposure, could trigger an out-of-bounds read in kernel context in cypress_read_int_callback(). The most likely technical outcomes are kernel warning/oops, driver instability, or denial of service; on hardened/debug kernels KASAN can detect this as a slab-out-of-bounds read. The patch adds packet-length validation and ignores malformed short reports before resubmitting the interrupt URB.

Why it matters to the business

Systems that accept untrusted USB devices, use Cypress M8-compatible USB serial adapters, or expose USB devices into virtualized/embedded environments may be vulnerable to crashes or instability caused by a malformed device report. The risk is lower than network-exploitable flaws because exploitation generally requires local physical USB access or control of a passed-through USB device, and the EPSS score is low with no known KEV listing or mature public exploit reported. Operational impact is most relevant for kiosks, industrial systems, labs, field devices, or servers where USB serial adapters are used for console, telemetry, point-of-sale, or equipment control.

How an attack unfolds

An attacker first obtains the ability to present a USB device to a vulnerable Linux system, either physically, through a malicious peripheral, through compromised USB hardware, or through USB passthrough into a VM or containerized hardware workflow. The device enumerates in a way that causes the kernel to bind the cypress_m8 USB serial driver. During interrupt-in transfers, the device returns a packet shorter than the header required by the selected Cypress packet format. On an unpatched kernel, cypress_read_int_callback() attempts to read header data that is not present in the completed buffer, causing an out-of-bounds read in kernel memory. Depending on kernel configuration and runtime behavior, this can result in a KASAN report, kernel oops/panic, USB serial driver malfunction, or broader system instability.

How to fix it

Update the Linux kernel to a version from the distribution or vendor that includes the fix for “USB: serial: cypress_m8: validate interrupt packet headers.” No exact fixed package versions were provided in the input, so use vendor security advisories, kernel changelogs, or backport notes to identify the corrected build for each supported distribution. If immediate patching is not possible, reduce exposure by disabling or blacklisting the cypress_m8 driver where it is not required, preventing untrusted USB devices from being connected, disabling USB passthrough for untrusted guests, and applying physical port controls on systems that do not need USB serial devices. For high-assurance environments, restrict kernel module auto-loading and allow only approved USB device classes or vendor/product IDs.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package includes the patch that validates Cypress M8 interrupt packet header lengths before parsing. Check distribution changelogs or source trees for the relevant cypress_m8.c change in drivers/usb/serial/cypress_m8.c. On systems where the driver is not needed, validate that the module is not loaded and cannot be auto-loaded, for example by checking lsmod for cypress_m8 and confirming any blacklist or module policy is effective. Confirm exposure by identifying systems with CONFIG_USB_SERIAL_CYPRESS_M8 enabled, the cypress_m8 module present, or active Cypress M8 USB serial devices under sysfs. If test hardware or a controlled USB fuzzing setup is available, malformed short interrupt packets should be ignored on fixed kernels rather than producing KASAN, oops, or panic messages.

Typical attack path

1. Gain physical or logical ability to attach or emulate a USB device to the target Linux system.
2. Present a USB serial device that binds to the cypress_m8 kernel driver.
3. Negotiate or trigger the Cypress packet format used by the driver.
4. Send a malformed short interrupt-in report that is shorter than the expected packet header.
5. Cause cypress_read_int_callback() to read past the completed USB buffer.
6. Leverage the resulting kernel fault or driver instability to disrupt the system or connected serial workflow.

How to detect it

Look for evidence of attempted or successful triggering in kernel and system logs, especially around USB device insertion, USB serial driver binding, and unexpected kernel crashes. Relevant log sources include dmesg, journald, /var/log/kern.log, /var/log/messages, crash dumps, pstore/ramoops, KASAN reports, and hypervisor logs if USB devices are passed through to guests. Investigate KASAN slab-out-of-bounds reports or kernel oops traces that reference cypress_read_int_callback(), drivers/usb/serial/cypress_m8.c, __usb_hcd_giveback_urb(), or repeated malformed/short USB interrupt transfers associated with Cypress M8 USB serial devices. Also review recent USB attach/detach history for unknown serial adapters, unexpected vendor/product IDs, or devices connected shortly before a kernel fault. Because exploitation may leave no persistent file artifacts, absence of logs does not prove absence of attempts if kernel logs rotated or the system crashed before logs were persisted.

• KASAN: slab-out-of-bounds in cypress_read_int_callback
• KASAN slab-out-of-bounds in cypress_read_int_callback
• cypress_read_int_callback+0x
• drivers/usb/serial/cypress_m8.c
• __usb_hcd_giveback_urb
• dummy_timer
• cypress_m8
• /sys/bus/usb-serial/drivers/cypress_m8
• /sys/module/cypress_m8
• USB: serial: cypress_m8
• Read of size 1

What your security team should do

• Prioritize patching systems that allow physical USB access, use USB serial adapters operationally, or pass USB devices into virtual machines.
• Inventory Linux systems with the cypress_m8 driver available or loaded, and determine whether Cypress M8-compatible USB serial support is actually required.
• Disable or blacklist the cypress_m8 module on systems that do not need this hardware support.
• Restrict untrusted USB access using physical controls, USB authorization policy, device allowlisting, or endpoint control tooling.
• Review virtualization and remote-access workflows that expose USB devices to Linux guests, and disable USB passthrough where unnecessary.
• Monitor kernel logs for KASAN, oops, panic, or USB serial errors referencing cypress_read_int_callback or cypress_m8.
• Treat unexplained crashes following USB device insertion as potentially security-relevant and preserve kernel logs for analysis.