Zephyr RTOS EUVD-2026-88471

Exploitation as a privilege-escalation/DoS primitive requires ALL of: (1) a Zephyr build compiled with CONFIG_USERSPACE so adc_read()/adc_read_async() are system calls; (2) use of the NXP MCUX LPADC driver (adc_mcux_lpadc.c) in interrupt-driven mode, or DMA-driven mode on releases that include the DMA path; and (3) an attacker-controlled unprivileged user-mode thread that has been granted access to the LPADC device object, giving it control over channels, buffer, buffer_size and options->extra_samplings. The attacker crafts a sequence requesting far more samples than the buffer holds (up to channels × 65536 into a two-byte buffer). Limiting factors: local access only (no remote vector), the thread must already hold the device-object grant, and builds WITHOUT CONFIG_USERSPACE are affected only as a caller-side robustness defect because the application itself supplies the buffer.

This is a genuine local privilege-escalation and denial-of-service primitive, not an inflated high-CVSS score. The vendor CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 7.8) is internally consistent with the description: an unprivileged user-mode thread (PR:L) that has been granted access to an LPADC device object can trigger kernel-mode out-of-bounds writes of attacker-chosen length and offset with no user interaction and low complexity. The high C/I/A ratings are justified because the writes occur in kernel context (ISR or DMA callback) where the MPU does not enforce the thread's memory domain, so corruption reaches other partitions, kernel data and thread stacks. Signals are LIMITED on the exploitation side: no EPSS score, no CISA KEV listing, and no public POC were provided, so real-world exploitation is unproven - appropriate given this is a local-only bug in an embedded RTOS driver rather than a network-facing service. The one caveat is scope: the vendor marks S:U, but a user-to-kernel memory corruption arguably crosses a security boundary (S:C); this does not change the local, authenticated-context nature of the flaw. Overall a real but conditionally-triggered priority - meaningful for security-critical Zephyr deployments using the NXP LPADC with CONFIG_USERSPACE, low practical risk elsewhere.

On a Zephyr build with CONFIG_USERSPACE enabled, a low-privileged user-mode thread that has been granted access to an NXP MCUX LPADC device object calls adc_read()/adc_read_async() with a small buffer (e.g. two bytes) but selects multiple channels and a large options->extra_samplings count. Because mcux_lpadc_start_read() performs no buffer-size validation, the driver writes up to channels × 65536 16-bit samples via an unbounded *data->buffer++ in kernel-mode ISR/DMA context, walking out of the user partition into kernel data and thread stacks. No public exploit code was identified at time of analysis; the fix and advisory ship a validation helper rather than a weaponized POC.