CVE-2026-19669: Unbounded variable-length array in fuel gauge syscall verifiers allows kernel stack overflow from user mode
The user-mode syscall verifiers zvrfyfuelgaugegetprops() and zvrfyfuelgaugesetprops() in drivers/fuelgauge/fuelgaugesyscallhandlers.c declared two variable-length arrays, union fuelgaugepropval kvals[len] and fuelgaugepropt kprops[len], sized directly by the caller-supplied len argument. len is an unvalidated sizet taken straight from the syscall ABI, and the VLAs were allocated before any check at all — including before the KSYSCALLDRIVERFUELGAUGE() object-permission check. The subsequent kusermodefromcopy() calls validated only that the user source buffer was readable; the kernel destination was never bounds-checked, since it was sized by the same attacker-chosen len.
Any thread running in user mode with CONFIGUSERSPACE enabled can invoke fuelgaugegetprops() or fuelgaugesetprops() with a large len. This first displaces the supervisor stack pointer by an arbitrary attacker-chosen amount — Zephyr does not build with stack-clash probing, so the displacement itself does not fault, and the nested calls made by the verifier then write frames below the privileged stack. If the caller has been granted access to a fuel-gauge device object, the memcpy inside kusermodefromcopy() additionally writes len sizeof(union fuelgaugepropval) bytes of fully attacker-controlled data starting well below the stack base. CONFIGPRIVILEGEDSTACKSIZE defaults to 1024 bytes, so a len of roughly 170 already exhausts it.
The result is an out-of-bounds write in supervisor mode with attacker-controlled length and, on the permitted path, attacker-controlled content — a break out of the user-mode sandbox into kernel memory, leading to kernel code execution or a system crash. A stack guard region does not contain it, because the copy begins below the guard and walks upward, corrupting unprotected memory before the guard is reached. The fix removes the kernel-side copies entirely and validates the caller's arrays in place with KSYSCALLMEMORYARRAYREAD() / KSYSCALLMEMORYARRAYWRITE(), which also handle the len size multiplication overflow; this is safe because neither fuelgaugepropt nor union fuelgaugepropval contains embedded pointers.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed?
The issue affects Zephyr builds with CONFIG_USERSPACE enabled. A thread running in user mode can supply a large len value to the affected fuel-gauge syscalls.
Does an attacker need prior access to a fuel-gauge device object?
The variable-length arrays are allocated before the fuel-gauge object-permission check. The description states that any user-mode thread can invoke the affected calls with a large len; access to a device object is checked only afterward.
What attacker capability is required?
Exploitation requires local code execution as a user-mode thread capable of invoking fuel_gauge_get_props() or fuel_gauge_set_props(). No user interaction is required, and the attacker controls the len argument directly through the syscall ABI.
Why can a large len value cause privileged-stack corruption?
The caller-controlled len directly determines two arrays allocated on the kernel stack, without validation. Zephyr does not use stack-clash probing, so the resulting stack-pointer displacement does not itself fault, while nested verifier calls can write stack frames below the privileged stack.