CVE-2026-63900

What it actually does

This flaw is an improper input-validation issue in the Linux kernel Keyspan USB serial driver. The driver did not sufficiently verify the size of USA-49WG input data transfers before parsing them, which could cause the kernel to process stale or uninitialized slab memory as if it were valid device data. The practical impact is most likely incorrect driver behavior, potential exposure of kernel memory-derived data through driver-controlled paths, or local denial-of-service conditions on systems that load and use the affected Keyspan USB serial support. Exploitation generally requires a malicious or compromised USB serial device, physical access, or an equivalent USB redirection/USB-over-IP path; it is not a typical network-reachable remote vulnerability.

Why it matters to the business

The main business risk is to Linux endpoints, appliances, lab systems, industrial workstations, or servers that allow USB peripherals and have the Keyspan USB serial driver available. An attacker with physical or proxied USB access could potentially destabilize affected systems or abuse driver behavior in environments that rely on USB serial connectivity. Current exploitation signals are low: EPSS is 0.00211, it is not listed in CISA KEV, it is not marked as ransomware-used, and no public exploit maturity is reported. Organizations should still remediate through normal kernel update cycles, with higher urgency for shared workstations, kiosks, industrial systems, labs, or high-trust hosts where untrusted USB devices may be connected.

How an attack unfolds

An attacker first needs a path to present a crafted USB serial device to a vulnerable Linux host, such as physical access to a USB port, a malicious peripheral, a compromised USB device, or a USB redirection channel. The device must be recognized by the Keyspan USB serial driver, specifically the USA-49WG handling path. The attacker then sends an input transfer whose length is smaller than the driver expects. Because the vulnerable code does not adequately sanity-check the transfer size, the kernel driver may parse bytes that were not actually supplied by the USB device and instead come from stale or uninitialized slab memory. Depending on surrounding kernel state and how the parsed fields influence the driver, this may lead to incorrect serial status handling, exposure of unintended memory-derived values, or instability. There is no indication from the provided intelligence that this is being exploited in the wild or that it has a mature public exploit.

How to fix it

Apply the Linux kernel update that includes the Keyspan USB serial driver fix for the missing USA-49WG input-transfer size check. Because no exact affected products or fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution, vendor, or appliance maintainer. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the Keyspan USB serial driver if it is not required, restricting physical USB access, using USB device-control tooling such as USBGuard, disabling USB redirection from untrusted sources, and allowing only approved USB serial adapters. Systems that require Keyspan USB serial hardware should be prioritized for vendor kernel updates rather than relying solely on access controls.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the upstream fix for the Keyspan USA-49WG input-transfer sanity check or by validating against the distribution/vendor security advisory for this CVE. Check whether the keyspan module is present or loaded using standard Linux tooling such as lsmod, modinfo, and kernel package inventory commands. If the driver is not needed, confirm it is blocked from loading through module blacklist policy and test that attaching a Keyspan-compatible device does not load the module. For exposed systems, review dmesg, journald, and kernel logs for recent Keyspan USB serial device enumeration and unexpected USB serial activity. Where feasible, perform validation in a test environment by attaching legitimate supported hardware after patching and confirming normal serial functionality without kernel warnings, oopses, or driver errors.

Typical attack path

1. Identify a Linux system where USB devices can be attached or redirected.
2. Present a malicious or modified USB device that is handled by the Keyspan USB serial driver, particularly the USA-49WG code path.
3. Trigger device enumeration so the kernel loads or uses the vulnerable keyspan driver.
4. Send a malformed input transfer with an insufficient length.
5. Cause the driver to parse stale or uninitialized slab data as valid transfer contents.
6. Attempt to observe driver misbehavior, data exposure through serial interfaces, or system instability.

How to detect it

To determine whether this may have been exploited, focus on evidence of unexpected USB serial device attachment and abnormal kernel behavior. Review kernel logs, dmesg output, journald, endpoint telemetry, and USB device inventory for Keyspan or USA-49WG device enumeration, especially on systems where those adapters are not approved or expected. Look for the keyspan module loading shortly before kernel warnings, oopses, crashes, hung tasks, unexpected ttyUSB device creation, or serial-device errors. Correlate physical access records, USB device-control logs, EDR device events, and remote USB redirection logs with the timestamps of any Keyspan driver activity. There are no known public exploitation-specific indicators from the provided intelligence, so detection should be behavior- and exposure-based rather than signature-based.

What your security team should do

• Inventory Linux systems that allow USB peripheral attachment or USB redirection and determine whether the keyspan USB serial driver is present or loaded.
• Patch affected Linux kernels through the appropriate distribution or vendor update channel; prioritize systems in shared, physical-accessible, lab, industrial, and appliance-like environments.
• If Keyspan USB serial support is not required, blacklist or disable the keyspan module and enforce USB device allowlisting.
• Review endpoint and kernel logs for unexpected Keyspan USB serial device enumeration, especially on systems where such adapters are not normally used.
• Restrict physical USB access and disable untrusted USB-over-IP or remote USB redirection pathways.
• Monitor vendor advisories for exact fixed kernel package versions because none were provided in the input intelligence.
• Treat any kernel crash, oops, or anomalous USB serial behavior following unexpected USB device attachment as potentially suspicious and preserve logs for investigation.