CVE-2026-63903

What it actually does

This flaw is an out-of-bounds or stale-byte read in the Linux kernel USB serial Belkin driver, specifically in the interrupt callback that parses modem and line status data. The driver expects a four-byte interrupt status report and reads fields at offsets 2 and 3, but USB interrupt transfers can complete successfully with fewer bytes than expected. A malformed, emulated, or physically connected USB serial device can return a short interrupt packet and cause the kernel to read beyond the valid received data. The most likely impact is kernel memory safety violation leading to a crash, KASAN report, or denial of service; depending on surrounding memory state and kernel configuration, stale status interpretation may also cause incorrect serial line behavior.

Why it matters to the business

Systems that load the affected Belkin USB serial driver may be destabilized by a malicious or malfunctioning USB device, which can cause unexpected kernel errors or crashes. The practical business risk is highest for workstations, kiosks, lab systems, industrial systems, hypervisors, or servers that allow physical USB access or USB device passthrough. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so internet-scale exploitation is unlikely; however, organizations with exposed physical ports or untrusted USB workflows should still treat it as a kernel reliability and local attack-surface issue.

How an attack unfolds

An attacker needs the target system to enumerate an affected USB serial device using the Linux belkin_sa driver. This can be done by connecting a malicious physical USB device, using a programmable USB gadget, or abusing USB passthrough into a Linux guest. Once the driver binds to the device, the attacker sends an interrupt-in transfer that completes successfully but contains fewer than the four bytes expected by the driver. The vulnerable callback then parses line-status and modem-status bytes at offsets that are not present in the received packet. This can trigger a kernel out-of-bounds read detected by KASAN, produce incorrect serial status handling, or cause a kernel crash or instability.

How to fix it

Update the Linux kernel to a version that includes the belkin_sa interrupt status length validation fix. If vendor kernel advisories are available for the distribution or appliance, apply the vendor-provided kernel update rather than only relying on upstream version numbers. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the belkin_sa module if Belkin USB serial adapters are not required, restricting physical USB access, disabling unused USB ports in firmware or operating system policy, and preventing USB passthrough from untrusted endpoints into virtual machines. Example mitigation options include unloading the module with modprobe -r belkin_sa and adding a modprobe blacklist rule for belkin_sa, subject to operational testing.

How to confirm the fix worked

Confirm the running kernel includes the fix by checking the distribution’s kernel changelog or security advisory for CVE-2026-63903 or the belkin_sa interrupt status length validation patch. Verify the active kernel version after reboot with uname -a and ensure the patched kernel is the one actually running. If using mitigation instead of patching, verify the belkin_sa module is not loaded with lsmod and that blacklist policy prevents it from loading when a matching USB serial device is attached. For regression validation, connect legitimate Belkin USB serial hardware if used operationally and confirm normal serial behavior while monitoring dmesg or journalctl for USB serial errors, kernel warnings, KASAN reports, or oops messages.

Typical attack path

1. Gain physical access to a system with USB enabled, or access a path that allows USB device passthrough or emulation.
2. Present a USB serial device that binds to the Linux belkin_sa driver.
3. Cause the device to generate a short successful interrupt-in status packet.
4. Trigger belkin_sa_read_int_callback() while the packet length is less than four bytes.
5. Induce an out-of-bounds or stale status-byte read in kernel context.
6. Observe kernel instability, crash, KASAN warning, or incorrect USB serial behavior.

How to detect it

Look for evidence of the vulnerable path being triggered in kernel logs and system journals. Primary sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, pstore records, and kernel oops or panic reports. Search for KASAN slab-out-of-bounds reports referencing belkin_sa_read_int_callback, USB serial driver messages involving belkin_sa, repeated USB disconnect/reconnect activity around the time of a crash, and call traces involving __usb_hcd_giveback_urb. If USB auditing or endpoint telemetry is available, correlate suspicious new USB serial device enumeration with kernel warnings or crashes. Because public exploitation is not known and this flaw does not create a distinctive network artifact, detection is primarily host-forensic and kernel-log based rather than network-based.

• BUG: KASAN: slab-out-of-bounds in belkin_sa_read_int_callback()
• belkin_sa_read_int_callback
• drivers/usb/serial/belkin_sa.c
• __usb_hcd_giveback_urb
• USB: serial: belkin_sa
• belkin_sa
• slab-out-of-bounds
• Read of size 1
• dummy_timer
• /var/log/kern.log
• /var/log/messages
• journalctl -k

What your security team should do

• Inventory Linux systems that permit physical USB access, USB device passthrough, or use Belkin USB serial adapters.
• Prioritize kernel updates for endpoints, kiosks, lab machines, virtualization hosts, and operational technology systems where untrusted USB devices may be attached.
• If the driver is not required, blacklist or disable the belkin_sa kernel module as a compensating control.
• Restrict physical USB access and enforce removable-device controls for shared workstations and sensitive systems.
• Review kernel logs for belkin_sa, KASAN, slab-out-of-bounds, or USB serial crash indicators to identify possible prior triggering.
• Ensure EDR, SIEM, or endpoint log collection includes kernel logs from Linux systems where USB attack surface is relevant.
• Track vendor advisories for the exact fixed kernel package applicable to each Linux distribution in use.