Zephyr MCTP CVE-2026-85032

Requires a device built with the experimental CONFIG_MCTP_USB class (MCTP subsystem is marked EXPERIMENTAL and compiled only with this option), and the attacker must be the USB host physically attached to the bulk OUT endpoint (AV:P). Exploitation is a race: the host drives both entry points into mctp_usb_class_disable() (SET_CONFIGURATION and USB bus reset via usbd_config_reset()) to time teardown against the RX worker. The instruction-level use-after-free WRITE window additionally requires genuine parallelism - CONFIG_SMP or a preemptible CONFIG_SYSTEM_WORKQUEUE_PRIORITY - whereas the kernel default is cooperative (priority -1). Under that default cooperative workqueue only the NULL-dereference crash variant is reachable (the worker must yield inside mctp_bus_rx() via an application callback or a control-message reply blocking in mctp_usb_tx()), and that fault only manifests on targets with null-pointer detection. No credentials or user interaction are needed. Affected versions are >=4.4.0, <4.5.0; the only complete fix per the vendor is updating to 4.5.0 or taking the backport.

This is a genuine but low-urgency issue, correctly rated moderate (CVSS 4.8) rather than critical. The strongest limiting signal is the CVSS attack vector AV:P (physical): the attacker must be the USB host physically attached to the Zephyr device, which rules out remote/network exploitation entirely. AC:H reflects that this is a use-after-free race (CWE-416) requiring the attacker to win a timing window between the RX worker and the host-triggered disable handler. Impact is bounded - C:N (no confidentiality impact established), I:L, A:H - consistent with the reporter's own conclusion that the PoC demonstrates memory corruption and denial-of-service but does NOT establish RCE or arbitrary read/write. No CISA KEV listing and no EPSS score are provided, so there is no evidence of active or widespread exploitation; the vuln.today Decision label is 'this_month', not act_now/emergency. A public PoC exists but was dynamically confirmed only on the native_sim virtual-USB path (Zephyr v4.4.2); the reporter explicitly notes real-hardware reproduction is unverified and a 1,000-iteration virtual SET_CONFIGURATION stress test did not crash. Conflict to note: the 'Information Disclosure' tag is not supported by the evidence - the CVSS vector and the reporter both indicate C:N with no arbitrary read demonstrated. Net: a real bug worth patching within the vendor's monthly cadence, but its physical attack vector plus experimental, opt-in subsystem status make it far lower real-world priority than its CWE class alone would suggest.

An attacker who can attach a malicious USB host to a Zephyr device built with the experimental CONFIG_MCTP_USB class streams partial MCTP frames on the bulk OUT endpoint while repeatedly issuing SET_CONFIGURATION requests or forcing USB bus resets, so the host controls both the data being parsed and the moment the teardown runs and can retry the race indefinitely. If the free in mctp_usb_reset_rx_state() lands while the RX worker still holds usb->rx_pkt, the worker writes host-supplied bytes into freed MCTP-heap memory (corrupting recycled buffers or sys_heap metadata); with the default cooperative workqueue the worker instead resumes after a yield and dereferences the NULLed pointer, faulting the device. A public PoC exists demonstrating the race on the native_sim virtual-USB path, but real-hardware exploitation is not verified.