CVE-2026-63897

What it actually does

This vulnerability is an information disclosure flaw in the Linux kernel USB serial mct_u232 driver. The driver failed to validate the length of interrupt-in USB transfers before parsing status data. A malformed or malicious USB serial device could send a shorter-than-expected interrupt transfer, causing the kernel driver to read stale or uninitialized slab memory and potentially expose that data to user space through the device interface. The flaw does not directly provide code execution or privilege escalation, but it can leak kernel memory contents that may aid further exploitation.

Why it matters to the business

Systems that allow untrusted USB devices to be connected could unintentionally expose sensitive kernel memory data to a local user or to software interacting with a malicious USB serial adapter. The operational risk is highest for workstations, kiosks, lab systems, industrial systems, or administrative machines where physical USB access is possible. Current public exploitation likelihood appears low, with low EPSS, no known CISA KEV listing, no ransomware association, and no mature public exploit reported, but kernel memory disclosure issues should still be remediated as part of normal kernel patch management.

How an attack unfolds

An attacker needs a path to present a malicious or malformed USB serial device that is handled by the Linux mct_u232 driver. After the device is connected and bound to the driver, the attacker-controlled device sends an interrupt-in transfer with an invalid short length. Because vulnerable kernels do not sufficiently check the transfer size, the driver may parse bytes that were not actually supplied by the device and instead come from stale or uninitialized kernel heap memory. A local process that can access the resulting USB serial device interface may then receive or infer leaked kernel memory contents. The attacker can use the disclosure to collect sensitive fragments or to weaken mitigations for a separate local exploit, but this vulnerability by itself is not a network-reachable compromise path.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the mct_u232 interrupt-in transfer size validation issue. If vendor-specific fixed kernel versions are not available, update to the latest supported kernel package from the Linux distribution or appliance vendor once it incorporates the patch. As interim mitigation, restrict physical USB access, disable or block untrusted USB devices, and prevent automatic binding of the mct_u232 driver where the device is not required. On systems that do not use MCT U232 USB serial adapters, consider blacklisting the mct_u232 kernel module until patched, using a modprobe blacklist entry such as `blacklist mct_u232`, while validating that no legitimate workflows depend on it.

How to confirm the fix worked

Confirm the running kernel package is updated to a vendor release that contains the mct_u232 sanity-check fix. Verify whether the mct_u232 driver is present or loaded using commands such as `lsmod | grep mct_u232`, `modinfo mct_u232`, and distribution package metadata for the running kernel. If mitigation is used, confirm the module cannot be autoloaded and that relevant USB serial devices do not bind to mct_u232. For deeper validation, review the kernel source or vendor changelog for the USB serial mct_u232 interrupt-in transfer size check, or perform controlled testing with a malformed USB device in a lab and confirm the kernel no longer parses short interrupt-in transfers or leaks uninitialized data.

Typical attack path

1. Attacker obtains physical access to a Linux system or convinces a user/operator to attach a malicious USB serial adapter.
2. The malicious device enumerates as hardware supported by the mct_u232 USB serial driver.
3. The vulnerable kernel binds the device to the mct_u232 driver.
4. The device sends a malformed or undersized interrupt-in transfer.
5. The driver parses data without adequate length validation and reads stale or uninitialized slab memory.
6. A local user-space process interacting with the serial device receives or observes leaked kernel memory data.
7. The attacker analyzes the leaked data for sensitive values or uses it to support a separate exploit chain.

How to detect it

This issue is difficult to detect after exploitation because it may only involve normal USB enumeration and interrupt transfers, and leaked memory may be consumed by a local process without creating distinctive logs. Review kernel logs, audit logs, endpoint telemetry, and USB device-control logs for unexpected MCT U232-compatible USB serial devices, new ttyUSB devices, repeated attach/detach activity, or unknown USB vendor/product identifiers around the time of concern. Useful log sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, auditd execution and device access records, EDR USB telemetry, and physical access control events. Investigate local processes that opened newly created `/dev/ttyUSB*` devices shortly after suspicious USB insertion. There are no reliable network indicators because exploitation is local/physical through USB rather than remote over the network.

• mct_u232
• mct_u232 converter now attached to ttyUSB
• usbserial: USB Serial support registered for MCT U232
• /dev/ttyUSB
• ttyUSB
• kernel: usb
• kernel: usbserial

What your security team should do

• Prioritize patching Linux endpoints and appliances where users or external parties can connect USB devices, including workstations, kiosks, shared lab systems, industrial operator stations, and field-service laptops.
• Inventory systems where the mct_u232 driver is loaded or available and determine whether MCT U232 USB serial adapters are operationally required.
• If the driver is not required, blacklist or disable `mct_u232` as a compensating control until kernel updates are deployed.
• Restrict physical USB access and enforce USB device control policies for sensitive systems.
• Monitor kernel and distribution advisories for the exact fixed kernel packages applicable to supported Linux platforms.
• Treat any suspicious newly attached USB serial device on an unpatched host as a potential data-exposure event and preserve logs for review.