Zephyr RTOS CVE-2026-10656

Physical USB bus access is the sole prerequisite: the attacker must be the USB host connected to the target device's USB port. The target must be running Zephyr v4.4.0 or a later unpatched build and must be built for hardware using the MAX32xxx USB device controller (DTS compatible string adi_max32_usbhs). Exploitation requires initiating an EP0 control transfer and then issuing a new SETUP packet before the driver thread processes the completion event - this is legal USB behavior achievable with any programmable USB host adapter or a Linux host with libusb/gadget tools. No authentication is required because the attacker operates as the USB host, not as a software-layer principal. Exploitation is bounded by: (1) physical USB port access only - no network-based attack path exists; (2) the specific MAX32xxx hardware family - devices using other Zephyr USB UDC drivers are unaffected; (3) impact limited strictly to device crash/reset with no code execution or data exfiltration possible.

The CVSS 3.1 vector CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (score 4.6, Medium) accurately characterizes this as a physical-access-only denial-of-service issue. AV:P is the dominant risk limiter: an attacker must have physical USB bus access to the target device, which eliminates the vast majority of remote threat actors. AC:L and PR:N reflect that once physical access is obtained, no authentication or special configuration is needed - sending a SETUP packet is standard USB behavior. Impact is constrained entirely to availability (A:H); there is no confidentiality or integrity impact, and scope is unchanged (S:U), meaning the crash is contained to the affected device. No EPSS data was available in the input; given the physical access requirement and niche hardware dependency, real-world exploitation probability would be expected to be low. The vulnerability is not listed in CISA KEV and no POC code has been identified, further supporting a lower operational priority. This is a genuine risk for embedded product manufacturers shipping devices with MAX32xxx USB controllers on Zephyr v4.4.0, particularly in contexts where the USB port is exposed to untrusted hosts (public kiosks, shared lab equipment, field-deployed sensors). For those specific deployments it warrants patching; for organizations with no MAX32xxx hardware, it is irrelevant.

An attacker with physical access to a device running Zephyr v4.4.0 on MAX32xxx hardware connects a programmable USB host (such as a Facedancer, GreatFET, or even a Linux host with raw USB gadget tools) and initiates an EP0 control transfer to the target device. Before the device driver thread processes the completion event, the attacker sends a new SETUP packet - a valid USB protocol action - which causes udc_setup_received() to drain the EP0 FIFOs, leaving udc_buf_get() returning NULL when the stale XFER_OUT_DONE event is finally processed, triggering net_buf_add(NULL, ...) and crashing the device. No public proof-of-concept code has been identified at time of analysis, but the triggering sequence requires only standard USB host functionality.