CVE-2026-63899

What it actually does

This vulnerability is a Linux kernel memory-corruption flaw in the USB serial mxuport driver. A malicious USB serial device can advertise a bulk-out endpoint with an unexpectedly small maximum packet size. If the driver accepts that value, later data handling can corrupt kernel slab memory in a user-influenced way. Depending on kernel configuration, heap layout, and exploit reliability, this could lead to kernel crash, denial of service, or potentially local privilege escalation through controlled kernel memory corruption. Exploitation requires the vulnerable driver to bind to a malicious or spoofed USB device; it is not a remotely exploitable network vulnerability.

Why it matters to the business

The primary business risk is disruption or compromise of Linux systems that allow untrusted USB devices or operate in environments where physical or peripheral access is possible, such as workstations, labs, kiosks, manufacturing systems, and field devices. Successful exploitation could crash affected systems or, in a more advanced scenario, allow an attacker with USB access to gain elevated control of the machine. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and currently has low EPSS and no public exploit maturity, so urgency is lower than for actively exploited remote flaws; however, organizations with exposed physical ports or strict endpoint-hardening requirements should still prioritize kernel updates and USB device-control policies.

How an attack unfolds

An attacker prepares a malicious USB device or USB-emulation platform that presents itself in a way that causes the Linux mxuport USB serial driver to bind to it. During USB enumeration, the device reports a bulk-out endpoint maximum packet size smaller than the driver safely expects. On vulnerable kernels, the driver can proceed with this invalid endpoint size. When the host interacts with the device, the malformed endpoint properties can trigger incorrect buffer handling and corrupt kernel slab memory. The immediate result may be a kernel panic or system instability. A sophisticated attacker may attempt to shape allocations and data transfers to turn the corruption into code execution in kernel context, which could allow privilege escalation from physical/peripheral access to full system compromise.

How to fix it

Update affected Linux kernels to a version that includes the mxuport driver fix requiring the bulk-out endpoint maximum packet size to be at least eight bytes. Because no specific affected product list or fixed package versions were provided, use the kernel packages from the relevant Linux distribution, vendor, or appliance supplier that include the upstream fix for this issue. Where immediate patching is not possible, reduce exposure by disabling or restricting USB access, enforcing USB device-control/allow-listing, disabling unused USB serial drivers where operationally feasible, blacklisting the mxuport module if it is not required, and preventing untrusted users from attaching USB devices. For high-assurance systems, combine kernel patching with physical port controls, BIOS/UEFI USB restrictions, endpoint device-control software, and monitoring for unexpected USB serial device enumeration.

How to confirm the fix worked

Confirm that systems are running a kernel build that contains the fix for the mxuport USB serial driver. Validate through vendor advisories, distribution changelogs, kernel package changelogs, or source-level confirmation that the driver rejects bulk-out endpoint maximum packet sizes smaller than eight bytes. On Linux systems, inventory running kernel versions and installed kernel packages, then compare them against vendor-fixed releases. If the mxuport driver is not needed, confirm it is not loaded and is blocked from loading. Operationally, test USB device-control policies by verifying that unauthorized USB serial devices are blocked or require approval. Exposure is greatest on systems where users or attackers can attach USB devices and where the mxuport driver is available to bind automatically.

Typical attack path

1. Obtain physical access to a Linux system or to a path where a USB device can be attached, such as a workstation, kiosk, embedded appliance, lab system, or server with accessible ports.
2. Connect a malicious USB device that emulates a vulnerable mxuport-compatible USB serial device.
3. During USB enumeration, have the device advertise a bulk-out endpoint maximum packet size smaller than eight bytes.
4. Cause the Linux kernel mxuport driver to bind to the device and initialize it using the malformed endpoint descriptor.
5. Trigger data transfer or driver behavior that relies on the invalid packet size.
6. Corrupt kernel slab memory, causing a crash or attempting to achieve controlled kernel memory corruption.
7. If exploit development is successful, escalate privileges or execute code in kernel context; otherwise, produce denial of service through system instability or kernel panic.

How to detect it

To determine whether exploitation may already have occurred, focus on endpoint, kernel, and physical-access telemetry rather than network logs. Review Linux kernel logs, system journals, audit logs, endpoint detection telemetry, and USB device inventory records for unexpected USB serial device attachment followed by mxuport driver initialization, kernel memory-corruption warnings, slab allocator errors, oops reports, or system crashes. Useful sources include journalctl, dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd logs, EDR USB-device events, udev logs where available, crash dumps, kdump/vmcore data, and fleet USB inventory tools. Investigate any sequence where a new USB serial device is attached, the mxuport driver loads, and the host soon reports slab corruption, invalid memory access, kernel panic, general protection fault, or unexplained reboot. Because the known exploit path requires a malicious or malformed USB device, also review physical access records, helpdesk tickets about unexpected reboots after USB insertion, and device-control alerts for unknown USB serial adapters. There are no known public attacker-specific payload strings, command-and-control indicators, or ransomware artifacts associated with this vulnerability as of the provided data.

• mxuport
• usbserial
• USB Serial support registered for mxuport
• new full-speed USB device
• new high-speed USB device
• new SuperSpeed USB device
• New USB device found
• bulk-out endpoint
• slab corruption
• kernel BUG at
• BUG: unable to handle kernel NULL pointer dereference
• BUG: unable to handle page fault
• general protection fault
• Oops:
• Kernel panic - not syncing
• bad page state
• use-after-free
• KASAN:
• UBSAN:
• kmalloc
• kfree
• usbcore: registered new interface driver mxuport

What your security team should do

• Prioritize patching Linux endpoints, kiosks, embedded systems, lab systems, and servers where untrusted physical access or USB device attachment is possible.
• Use distribution or vendor kernel updates that include the mxuport endpoint-size validation fix; do not rely on CVSS or EPSS alone for systems exposed to public or semi-public physical access.
• If mxuport USB serial support is not required, blacklist or disable the mxuport kernel module as a compensating control.
• Enforce USB device-control policies that allow only approved device classes and known device identifiers, especially for workstations, production systems, and shared-use devices.
• Review physical security controls for systems with accessible USB ports, including port locks, locked enclosures, and BIOS/UEFI restrictions where appropriate.
• Monitor for unexpected USB serial device enumeration, sudden mxuport driver loads, kernel warnings, general protection faults, slab corruption messages, or kernel panics following USB insertion.
• Include this issue in kernel vulnerability management workflows even though it is not currently KEV-listed and has no known public exploit maturity.
• For forensic triage, correlate USB attach events with crashes, privilege changes, suspicious local activity, or unusual kernel log messages.