CVE-2026-63898

What it actually does

This is a Linux kernel memory-corruption flaw in the USB serial mct_u232 driver. The driver adjusts the maximum bulk-out transfer size for a device that expects 16-byte packets, but the vulnerable logic can incorrectly increase the transfer size when a malicious or malformed USB device reports an unexpectedly small endpoint maximum packet size. That mismatch can cause writes beyond the intended slab allocation in kernel memory. Practical impact is most likely kernel crash or system instability, but kernel memory corruption flaws can sometimes be shaped into local privilege escalation depending on platform hardening, exploit reliability, and attacker control over USB device behavior.

Why it matters to the business

Systems that allow untrusted USB devices to be attached could be crashed or potentially compromised at the operating-system level. The main operational risk is disruption to Linux endpoints, kiosks, workstations, lab systems, embedded devices, or servers with exposed USB ports. Exploitation requires local or proximate access to present a malicious USB device, so internet-facing risk is low. EPSS is currently low and there is no known CISA KEV listing or ransomware association, but kernel flaws affecting physical interfaces should still be addressed on systems where USB access is not tightly controlled.

How an attack unfolds

An attacker prepares a malicious USB serial device, or a programmable USB emulator, that identifies in a way that causes Linux to bind it to the mct_u232 USB serial driver. During enumeration, the device advertises a smaller bulk-out endpoint maximum packet size than the driver expects. The vulnerable driver path then overrides transfer sizing in a way that can exceed the safe allocation boundary. When the host sends data through the serial interface, the oversized transfer can corrupt adjacent kernel slab memory. The attacker’s most reliable outcome is a kernel panic or denial of service; with additional exploit development, carefully controlled corruption could potentially be used to influence kernel state and escalate privileges. There is no indication of public exploit maturity, known weaponization, KEV listing, or ransomware use at this time.

How to fix it

Update the Linux kernel to a vendor-supported release that includes the upstream fix for the mct_u232 USB serial driver. Because no exact affected product list or fixed package versions were provided, use the relevant distribution or appliance advisory to identify the corrected kernel package for each platform. Where immediate patching is not possible, reduce exposure by disabling or blocking untrusted USB devices, restricting physical access to USB ports, disabling unused USB serial support, or preventing automatic loading of the mct_u232 module where operationally safe. On systems that do not require this driver, consider blacklisting the mct_u232 kernel module using the platform’s supported module-blocking mechanism and rebuilding initramfs if required by the distribution.

How to confirm the fix worked

Confirm that each system is running a kernel build containing the mct_u232 transfer-size fix from the vendor or upstream stable kernel. Validate through package inventory, kernel version checks, and distribution security advisory mapping rather than relying only on the running version string. Check whether the mct_u232 module is present or loaded with commands such as lsmod, modinfo, or distribution inventory tooling. If mitigations were applied, verify that the module cannot be automatically loaded and that connecting an MCT U232-compatible device no longer binds to the vulnerable driver. For high-assurance validation, test on a non-production system with representative USB policy controls and confirm there are no kernel warnings, slab corruption reports, or crashes during USB serial enumeration and transfer activity.

Typical attack path

1. Obtain local physical access to a Linux system or access to a path where a malicious USB device can be connected, such as a kiosk, workstation, lab host, or embedded device.
2. Prepare a malicious USB device or USB emulation platform that presents as an MCT U232-compatible USB serial adapter with a crafted endpoint descriptor.
3. Connect the device and cause the Linux kernel to bind it to the mct_u232 USB serial driver.
4. Trigger host-to-device serial traffic through the created ttyUSB interface.
5. Cause the vulnerable transfer-size handling to corrupt kernel slab memory.
6. Achieve denial of service through kernel crash, or attempt more advanced exploitation for kernel-level code execution or privilege escalation.

How to detect it

Retrospective detection is difficult because successful exploitation occurs inside kernel USB handling and may leave only crash or device-enumeration artifacts. Review kernel logs, system journal, crash dumps, and endpoint telemetry for recent attachment of MCT U232 or mct_u232 USB serial devices followed by kernel memory-corruption messages, KASAN reports, slab allocator warnings, oopses, panics, hung tasks, or unexpected reboots. Useful log sources include journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, kdump/vmcore artifacts, endpoint USB device-control logs, and physical access or EDR telemetry showing removable-device insertion. Focus on sequences where a USB serial device is enumerated, a ttyUSB interface is created, and the system crashes or reports slab corruption soon after serial traffic begins. There are no known threat actors or campaigns reported for this vulnerability, so detection should be behavior- and artifact-based rather than actor-based.

• mct_u232
• MCT U232
• ttyUSB
• usbserial
• USB Serial
• slab corruption
• slab-out-of-bounds
• BUG: KASAN
• KASAN: slab-out-of-bounds
• kernel BUG
• Oops:
• general protection fault
• BUG: unable to handle kernel
• Unable to handle kernel paging request
• mct_u232 converter now attached
• USB disconnect, device number

What your security team should do

• Prioritize patching Linux systems where users, visitors, contractors, or attackers could physically attach USB devices, including kiosks, shared workstations, manufacturing systems, labs, and exposed edge devices.
• Inventory systems with the mct_u232 driver available or loaded, and identify whether USB serial adapters are operationally required.
• Apply vendor kernel updates that include the fix; where exact fixed versions vary by distribution, track remediation through OS vendor advisories and kernel package changelogs.
• If patching is delayed, disable or blacklist the mct_u232 module on systems that do not require it, and enforce USB device-control policies where available.
• Restrict physical access to USB ports and use port blockers, BIOS/UEFI controls, endpoint device control, or kernel module policy for high-risk systems.
• Monitor kernel logs for USB serial enumeration followed by slab corruption, KASAN reports, oopses, or unexpected reboots.
• Treat suspicious crashes after USB device insertion as potential security events and preserve kernel logs, crash dumps, and connected-device details for investigation.
• Because EPSS is low, there is no KEV listing, and no mature public exploitation is known, rank this below remotely exploitable kernel vulnerabilities but above routine local-only bugs on physically exposed systems.