Zephyr-Saxon

**Name of the Vulnerable Software and Affected Versions** Zephyr (affected versions not specified) **Description** The NXP MCUX LPADC driver fails to validate the destination buffer size before starting a sampling sequence. Specifically, the `mcux lpadc start read()` function in `drivers/adc/adc mcux lpadc.c` does not check if the buffer is large enough to hold the requested samples. This leads to an out-of-bounds write in `mcux lpadc isr()` for interrupt-driven builds and `mcux lpadc dma callback()` for DMA-driven builds. In builds with `CONFIG USERSPACE` enabled, an unprivileged user-mode thread with access to an LPADC device object can manipulate `channels`, `buffer`, `buffer size`, and `options->extra samplings` to trigger kernel-memory corruption. Because the driver operates in kernel mode, it bypasses the Memory Protection Unit (MPU) restrictions, allowing writes into adjacent memory, kernel data, or thread stacks. This can result in privilege escalation or a denial-of-service. For builds without `CONFIG USERSPACE`, the issue is limited to a caller-side robustness defect. **Recommendations** Update the software to a version that implements the `adc sequence validate buffer()` helper function within `mcux lpadc start read()` to ensure the buffer size is validated before sampling begins.

**Name of the Vulnerable Software and Affected Versions** Zephyr (affected versions not specified) **Description** The ADI MAX32 driver fails to properly validate the destination buffer size for sampling sequences. The `start read()` function in `drivers/adc/adc max32.c` compares the `buffer size` byte count against a sample count without considering the size of a `uint16 t`, allowing buffers half the required size to be accepted. This leads to an out-of-bounds write when samples are stored via `Wrap MXC ADC GetData()` in `adc max32 start channel()` for synchronous reads or `adc max32 isr()` for asynchronous reads. In builds with `CONFIG USERSPACE`, where `adc read()` and `adc read async()` are system calls, an unprivileged user-mode thread with access to a MAX32 ADC device can control `channels`, `buffer`, `buffer size`, and `options->extra samplings`. This allows the driver to write beyond the buffer limit in kernel mode, bypassing MPU restrictions and corrupting adjacent kernel memory, other partitions, or thread stacks. This can result in privilege escalation or a denial-of-service. **Recommendations** Update the `start read()` function to use the `adc sequence validate buffer()` helper in `drivers/adc/adc common.c` to correctly validate the buffer size based on the sample size of `uint16 t`.