CVE-2026-19669: Unbounded variable-length array in fuel gauge syscall verifiers allows kernel stack overflow from user mode

Published Oct 11, 2026
·
Updated

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

1 affected component
Zephyr Project Zephyr

Event History

Oct 11, 2026
CVE Published
via MITRE·05:14 PM
Data Sourced
via MITRE·05:14 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·06:16 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

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.

2

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.

3

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.

4

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203