Zephyr RTOS EUVD-2026-97111

Requires the target firmware to be built with CONFIG_USERSPACE enabled and the attacker to already execute as a user-mode thread on the device. The denial-of-service / supervisor-stack-displacement path needs only that user-mode foothold plus a large caller-supplied len (≈170+ exhausts the default CONFIG_PRIVILEGED_STACK_SIZE of 1024 bytes), because Zephyr is not built with stack-clash probing so the displacement does not fault. The additional attacker-controlled-content write through k_usermode_from_copy() further requires that the calling thread has been granted access to a fuel-gauge device object (the K_SYSCALL_DRIVER_FUEL_GAUGE object-permission path). Limiting factors: exploitation is local only (no remote/network vector), is impossible on builds without CONFIG_USERSPACE or without a fuel-gauge driver, and full content control depends on fuel-gauge object permissions; a hardware stack guard does not stop it because the copy begins below the guard and walks upward.

This is a genuine, high-priority local privilege-escalation / sandbox-escape flaw rather than an inflated high-CVSS issue, but its risk is gated by deployment context. The vendor CVSS vector (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 7.8) is internally consistent with the description: exploitation is local (AV:L) by any thread already running in user mode (PR:L), with no user interaction and low complexity (AC:L), yielding full C/I/A impact via supervisor-mode out-of-bounds write (CWE-787). Exploitation status: no public exploit identified at time of analysis - the input provides no KEV listing and no POC, only a vendor patch and GHSA advisory, so there is no evidence of active exploitation. No EPSS score was supplied, so probabilistic exploitation likelihood cannot be quantified here. No SSVC decision data was provided. One nuance to verify: the description frames this as a 'break out of the user-mode sandbox into kernel memory,' which is arguably an SSVC/CVSS scope change (S:C), yet the vendor assigned S:U; defenders treating this as a pure same-scope local bug may underweight the sandbox-escape consequence. Net: real and serious for Zephyr builds with CONFIG_USERSPACE and untrusted user-mode threads, but there is no signal of opportunistic mass exploitation.

On a Zephyr device built with CONFIG_USERSPACE, a low-privileged user-mode thread (e.g. a sandboxed application component) calls fuel_gauge_get_props() or fuel_gauge_set_props() with an attacker-chosen len of roughly 170 or larger. The variable-length arrays are sized by that len and allocated on the privileged stack before any validation, displacing the supervisor stack pointer and, if the thread also holds permission to a fuel-gauge device object, letting k_usermode_from_copy() write fully attacker-controlled data below the stack base - corrupting kernel memory for code execution or crash. No public exploit code is identified at time of analysis.