Description

The NXP GAU ADC driver (drivers/adc/adc_mcux_gau_adc.c) validated the caller-supplied sequence->buffer_size, which is expressed in bytes, against the number of active channels, which is a sample count. It then stored that byte count directly in data->results_length and used it in mcux_gau_adc_read_samples() as the number of uint16_t slots available. Because each conversion result occupies sizeof(uint16_t) bytes, a buffer that was accepted as "large enough" could be written with up to twice its size in bytes, so every sample past the buffer's midpoint was written out of bounds. adc_read() and adc_read_async() are Zephyr system calls. The syscall verifier in drivers/adc/adc_handlers.c only confirms that the caller owns buffer_size writable bytes (K_SYSCALL_MEMORY_WRITE); deciding whether that size is sufficient for the requested channels and extra_samplings is delegated entirely to the driver. On a build with CONFIG_USERSPACE=y, a user-mode thread that has been granted the ADC device object could therefore submit a deliberately half-sized buffer and cause the driver's work-queue handler — which runs in supervisor mode, outside the caller's MPU restrictions — to write ADC conversion results past the end of that buffer, at an address and for a length of the caller's choosing. The overrun is bounded by the requested sequence: with sequence->options->extra_samplings set, the sampling loop walks the buffer pointer forward across every sampling, so the total overrun can reach the full size of the supplied buffer (kilobytes for a large extra_samplings). The written words are 16-bit ADC conversion results, so the content is only partially attacker-influenced (via the selected analog input, gain and resolution), but the destination and length are fully controlled — sufficient for kernel memory corruption, a crash, or a userspace-to-kernel privilege escalation. Builds without CONFIG_USERSPACE, or on SoCs other than NXP RW61x with the GAU ADC node enabled, are not exposed to the privilege boundary; there the same defect only causes a silent overflow when the application itself passes an undersized buffer. The fix replaces the ad-hoc check with the shared adc_sequence_validate_buffer() helper (validating against num_channels * sizeof(uint16_t)), stores buffer_size / sizeof(uint16_t) in results_length, and corrects the loop bound to a post-decrement so exactly the available number of slots may be written.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.4",
  "pubDate": "2026-10-05T09:17:12.907Z",
  "pubdate": "2026-10-05T09:17:12.907Z",
  "executiveSummary": "A critical out-of-bounds write vulnerability exists in the NXP GAU ADC driver (drivers/adc/adc_mcux_gau_adc.c) within the Zephyr RTOS.\nThe vulnerability arises from an incorrect validation of the user-provided buffer size versus the required sample capacity, leading to a heap-based buffer overflow in kernel memory.\nThe flaw allows a user-mode process with access to the ADC device to trigger a write operation that extends beyond the allocated user buffer boundaries.\nBecause the write operation occurs within a supervisor-mode work-queue handler, an attacker can corrupt kernel memory structures, leading to system crashes or potential privilege escalation.\nExploitation requires CONFIG_USERSPACE to be enabled and access to the NXP RW61x GAU ADC node.\nIn environments lacking CONFIG_USERSPACE, the vulnerability is limited to silent data corruption within the application process rather than a privilege boundary violation.",
  "technicalDetails": "The root cause of the vulnerability is a type-mismatch in input validation within the adc_mcux_gau_adc.c driver. The driver validates the caller-supplied sequence->buffer_size (measured in bytes) against the active channel count (measured in sample units).\nBecause each ADC conversion result occupies sizeof(uint16_t) bytes, the driver incorrectly treats the byte-count as a slot-count. Consequently, the driver accepts a buffer half the required size for the requested sampling operation.\nThe Zephyr syscall handler in drivers/adc/adc_handlers.c validates only that the user has writable memory permissions (K_SYSCALL_MEMORY_WRITE) for the provided buffer size. It delegates the specific sufficiency check of the buffer capacity to the driver itself, which fails to account for the disparity between byte-size and element-count.\nThe attack flow proceeds as follows: 1) An attacker with userspace access acquires a handle to the ADC device. 2) The attacker calls adc_read() or adc_read_async() with a deliberately undersized buffer, providing a sequence structure that implies a higher number of conversions than the buffer can accommodate. 3) The driver proceeds to store the provided byte count directly into data->results_length. 4) The mcux_gau_adc_read_samples() function, executing in supervisor mode, performs a loop based on the corrupted results_length. 5) As the driver iterates through the requested samples, it writes 16-bit results into the buffer. Once the midpoint of the buffer is reached, all subsequent writes occur out-of-bounds, overwriting adjacent kernel memory.\nBy manipulating sequence->options->extra_samplings, an attacker can extend the length of the out-of-bounds write to several kilobytes. While the written content consists of ADC data—which is only partially controllable by the attacker through analog input manipulation—the destination address and the extent of the write are fully controlled by the sequence parameters.\nThis overwrite capability allows for the corruption of kernel objects, function pointers, or data structures stored in the vicinity of the buffer in the heap. In a kernel-mode execution context, this serves as a primitive for arbitrary memory modification, facilitating control-flow hijacking or elevation of privilege to kernel level."
}