6.1
CVE-2026-10663
- EPSS 0.16%
- Veröffentlicht 12.07.2026 16:16:48
- Zuletzt bearbeitet 16.07.2026 19:30:34
- CVE-Watchlists
- Unerledigt
Use-after-free / double-free of the root USB device in the experimental USB host stack
In Zephyr's experimental USB host stack (CONFIG_USB_HOST_STACK), usbh_device_disconnect() (subsys/usb/host/usbh_device.c) freed the root usb_device slab object without clearing the cached pointer ctx->root. The bus removal handler dev_removed_handler() (subsys/usb/host/usbh_core.c) decides what to tear down solely from ctx->root, checking only that it is non-NULL. Because UHC controller drivers (e.g. uhc_max3421e, uhc_mcux_common) synthesize UHC_EVT_DEV_REMOVED directly from physical bus line state with no debounce or state guard, an attacker with physical USB access (or a rogue device that bounces its connection) can deliver a second device-removed event after a root device disconnect. The handler then re-enters usbh_device_disconnect() with the dangling pointer, locking a mutex inside the freed object (use-after-free), removing the freed node from the device list, and calling k_mem_slab_free() on the already-freed block (double-free). If the slab block has been reissued to a newly attached device in between, this corrupts a live object. Impact is denial of service (crash) and memory corruption; the attack vector is physical/local. The flaw was introduced in v4.4.0 by the connect/disconnect refactor and is fixed by clearing ctx->root in usbh_device_disconnect() before freeing.
Daten sind bereitgestellt durch National Vulnerability Database (NVD)
Zephyrproject ≫ Zephyr Version >= 4.4.0 < 4.5.0
VulnDex Vulnerability Enrichment
| Typ | Quelle | Score | Percentile |
|---|---|---|---|
| EPSS | FIRST.org | 0.16% | 0.054 |
| Quelle | Base Score | Exploit Score | Impact Score | Vector String |
|---|---|---|---|---|
| vulnerabilities@zephyrproject.org | 6.1 | 0.9 | 5.2 |
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
|
CWE-416 Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
https://github.com/zephyrproject-rtos/zephyr/commit/4b87a8f161a44cb19505fa97db7cf72f64d49165
https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-26q8-xjq3-f5p6