CVE-2026-64505

What it actually does

This flaw is an improper input validation issue in the Linux kernel USB gadget RNDIS function. The vulnerable code accesses fields in an RNDIS message header before confirming that the received buffer is long enough to contain those fields. A malformed or truncated RNDIS message sent to a Linux system operating as a USB RNDIS gadget can therefore cause out-of-bounds memory access in kernel context. The most likely impact is kernel crash or denial of service; depending on kernel build options, memory layout, and surrounding code paths, secondary impacts such as information exposure or harder-to-achieve memory corruption cannot be fully ruled out without product-specific analysis.

Why it matters to the business

Systems that expose Linux USB gadget RNDIS functionality can be disrupted by malformed USB network traffic, potentially causing device crashes, service outages, watchdog resets, or loss of network connectivity over USB. This is most relevant to embedded Linux devices, appliances, development boards, mobile/IoT products, and systems that present themselves as USB Ethernet/RNDIS devices. Current public exploitation signals are low: EPSS is 0.22%, it is not listed in CISA KEV, it is not associated with ransomware use, and no public exploit maturity is reported; however, kernel-level denial-of-service bugs can still matter in environments where physical or USB-adjacent access is plausible.

How an attack unfolds

An attacker needs a way to send crafted RNDIS traffic to a vulnerable Linux kernel instance that is configured to operate as a USB gadget using the RNDIS function. In a typical scenario, the attacker connects to or controls the USB host side of a link where the Linux device exposes RNDIS networking. The attacker then sends an intentionally short or malformed RNDIS packet whose buffer length is smaller than the header fields the kernel expects to read. The vulnerable kernel code processes the packet and accesses MessageType, MessageLength, DataOffset, or DataLength before validating that the full header is present. This can trigger an out-of-bounds access in kernel space, commonly resulting in a kernel oops, panic, interface reset, or device reboot. There is no indication from the supplied intelligence that this vulnerability is remotely exploitable over ordinary IP networking without access to the USB/RNDIS gadget communication path.

How to fix it

Update to a Linux kernel version or vendor-supplied firmware/kernel package that includes the upstream fix adding a length check for the RNDIS header in the USB gadget RNDIS receive path. Because no exact affected product list or fixed package versions were provided, use distribution, device vendor, BSP, or kernel-maintainer advisories to identify the corrected kernel build for each product line. Where immediate patching is not possible, disable USB gadget RNDIS functionality if it is not required, replace RNDIS with a safer or better-maintained USB networking mode where feasible, restrict physical and USB-host access to affected devices, and avoid connecting exposed devices to untrusted USB hosts. For embedded products, ensure the fix is incorporated into downstream kernel trees, board support packages, recovery images, and production firmware, not only development builds.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel or firmware includes USB gadget RNDIS support and whether it is enabled at runtime. Review kernel configuration for options such as CONFIG_USB_F_RNDIS, CONFIG_USB_CONFIGFS_RNDIS, or composite gadget configurations that instantiate RNDIS. On systems using configfs, inspect USB gadget configuration under /sys/kernel/config/usb_gadget/ for RNDIS functions. Validate remediation by confirming the running kernel package, firmware image, or source tree contains the patch that adds a minimum-length check before accessing RNDIS header fields in rndis_rm_hdr. Functional validation should include normal USB RNDIS connectivity tests and, in a controlled lab only, malformed short RNDIS-frame fuzz testing to confirm the device rejects the packet without kernel oops, panic, reset, or KASAN reports.

Typical attack path

1. Identify a Linux-based device or appliance that exposes USB RNDIS gadget functionality.
2. Gain physical, local, lab, supply-chain, malicious-host, or otherwise USB-adjacent access to the device's RNDIS interface.
3. Establish communication from the USB host side to the vulnerable RNDIS gadget endpoint.
4. Send a malformed or truncated RNDIS message shorter than the expected RNDIS header length.
5. Trigger vulnerable kernel parsing in the RNDIS receive path before header-length validation occurs.
6. Cause kernel out-of-bounds access, leading to crash, panic, interface failure, reset, or denial of service.

How to detect it

Look for evidence of attempted or successful exploitation in kernel logs, persistent crash logs, serial console captures, device-management telemetry, watchdog reset records, and firmware crash dumps. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, pstore/ramoops, netconsole output, embedded device crash partitions, and vendor device-health telemetry. Focus on events involving RNDIS, USB gadget networking, kernel oops or panic messages, KASAN/KMSAN reports, watchdog resets shortly after USB connection events, or stack traces referencing RNDIS receive/header-removal functions. Because this issue is triggered through USB gadget traffic, network IDS on ordinary IP networks is unlikely to see the malformed pre-IP RNDIS header unless instrumentation exists on the USB host or gadget test harness. Absence of logs does not prove absence of exploitation, since many embedded devices do not persist kernel crash records across reboot.

• rndis_rm_hdr
• usb_f_rndis
• f_rndis
• RNDIS
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: KASAN
• kernel BUG at
• Oops:
• Unable to handle kernel
• Kernel panic - not syncing
• watchdog: watchdog0: watchdog did not stop
• pstore
• ramoops
• /sys/kernel/config/usb_gadget/
• /sys/kernel/config/usb_gadget/*/functions/rndis
• CONFIG_USB_F_RNDIS
• CONFIG_USB_CONFIGFS_RNDIS

What your security team should do

• Prioritize inventory of Linux-based products, embedded devices, appliances, and development boards that expose USB RNDIS gadget functionality.
• Patch affected kernels or firmware through the relevant Linux distribution, device vendor, BSP provider, or internal kernel-maintenance process.
• If patching is delayed, disable RNDIS gadget mode where operationally feasible, especially on devices exposed to untrusted physical access or untrusted USB hosts.
• Treat this as lower internet-scale urgency because EPSS is low, it is not in KEV, and no exploit maturity is reported, but do not ignore it for physically exposed or field-deployed devices.
• Review downstream kernel forks to ensure the upstream fix has been backported and shipped in all supported firmware branches.
• Add regression tests or fuzz cases for truncated RNDIS messages in kernel, firmware, or device qualification pipelines.
• Monitor kernel crash telemetry and device reboot patterns for RNDIS-related oops, panic, KASAN, or watchdog events.
• Restrict use of USB data connections in sensitive deployments and prefer charge-only, port-control, or device-control policies where applicable.