Description
The ADC API requires each driver to reject a sampling sequence whose destination buffer is too small: the buffer_size field of struct adc_sequence in include/zephyr/drivers/adc.h documents that "the driver must ensure that samples are not written beyond the limit and it must return an error if the buffer turns out to be not large enough". The ADI MAX32 driver did not honour that contract. start_read() in drivers/adc/adc_max32.c compared buffer_size, a byte count, against a sample count ((1 + extra_samplings) channels), ignoring sizeof(uint16_t), so it accepted a buffer half the required size. The samples are then stored through the uint16_t data->buffer by Wrap_MXC_ADC_GetData(), which writes two bytes per sample and advances the pointer by one uint16_t: in adc_max32_start_channel() for synchronous reads, and in adc_max32_isr() for asynchronous ones. A sequence selecting two channels with a two-byte buffer, for example, passes the check and has its second sample written past the end of the buffer.

On a build with CONFIG_USERSPACE, adc_read() and adc_read_async() are system calls. The handler in drivers/adc/adc_handlers.c copies the sequence in from user memory, verifies only that [buffer, buffer + buffer_size) is writable by the calling thread, and rejects a user-supplied options->callback; it deliberately leaves the size arithmetic to the driver. A user-mode thread that has been granted access to a MAX32 ADC device object therefore fully controls channels, buffer, buffer_size and options->extra_samplings, and can make the driver write twice as many bytes as its buffer holds. Because the check scales with extra_samplings, the overrun equals the length of the buffer itself, up to channels * 65536 bytes past its end, since the sample pointer is only rewound on a repeat sampling, never on the extra samplings of a sequence.

The resulting stores are performed by the driver in kernel mode (in the system call itself, the ADC context timer, or the ADC interrupt handler for asynchronous reads), where the MPU does not restrict the thread's memory domain, so the write walks linearly out of the user partition and into adjacent memory such as other partitions, kernel data or thread stacks. The impact is kernel-memory corruption of attacker-chosen length at an attacker-chosen offset, a plausible privilege-escalation and denial-of-service primitive from an unprivileged user-mode thread. Builds without CONFIG_USERSPACE are affected only as a caller-side robustness defect, since the application itself supplies the buffer.

The fix replaces that check in start_read() with a call to the new shared helper adc_sequence_validate_buffer() in drivers/adc/adc_common.c, passing sizeof(uint16_t) as the sample size. The helper computes active_channels sizeof(uint16_t) (1 + extra_samplings) and returns -ENOMEM before any sampling is started.
Published: 2026-09-28
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Kernel Memory Corruption
Action: Patch
AI Analysis

Impact

An out‑of‑bounds write occurs when the ADI MAX32 ADC driver accepts a sampling sequence whose destination buffer is too small. The driver compares the buffer size (in bytes) against the number of samples, ignoring the fact that each sample is a 16‑bit value. As a result, two bytes are written for each sample, and the driver writes past the end of the user‑supplied buffer. The overflow occurs in kernel mode during the ADC read system call or its interrupt handler, bypassing normal memory protection. This allows an unprivileged user‑mode thread that has access to the ADC device to corrupt arbitrary kernel memory, creating a privilege‑escalation and denial‑of‑service vector.

Affected Systems

Zephyr Project Zephyr builds that include the ADI MAX32 ADC driver and enable CONFIG_USERSPACE are affected. Builds without user space support suffer only from a robustness flaw; the kernel memory corrupts only when a user‑mode thread can issue adc_read or adc_read_async calls to the device.

Risk and Exploitability

The CVSS base score is 7.8, indicating a high‑severity flaw. EPSS data is not available, and the vulnerability is not listed in CISA's KEV catalog. Exploitation requires a user‑mode thread that can access the ADC device, a likely scenario when drivers are exposed to application code. The attacker can select arbitrary buffer sizes and channel counts, causing the overflow to reach kernel structures, thread stacks, or other protected memory. Given the lack of kernel‑mode boundaries and the high impact of memory corruption, the risk is significant and should be addressed promptly.

Generated by OpenCVE AI on September 28, 2026 at 22:06 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the patch that replaces the buffer size check in start_read() with a call to adc_sequence_validate_buffer() from drivers/adc/adc_common.c, passing sizeof(uint16_t) as the sample size. This fixes the out‑of‑bounds write identified as CWE‑787.
  • Recompile the Zephyr firmware with the updated driver and deploy the new image to all affected devices.
  • If an immediate upgrade is not possible, mitigate by disabling CONFIG_USERSPACE for the ADC device or restricting user access to ADC device objects so that untrusted threads cannot invoke adc_read or adc_read_async.

Generated by OpenCVE AI on September 28, 2026 at 22:06 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 30 Sep 2026 17:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}

Mon, 28 Sep 2026 22:45:00 +0000

Type Values Removed Values Added
First Time appeared Zephyrproject
Zephyrproject zephyr
Vendors & Products Zephyrproject
Zephyrproject zephyr

Mon, 28 Sep 2026 20:30:00 +0000

Type Values Removed Values Added
Description The ADC API requires each driver to reject a sampling sequence whose destination buffer is too small: the buffer_size field of struct adc_sequence in include/zephyr/drivers/adc.h documents that "the driver must ensure that samples are not written beyond the limit and it must return an error if the buffer turns out to be not large enough". The ADI MAX32 driver did not honour that contract. start_read() in drivers/adc/adc_max32.c compared buffer_size, a byte count, against a sample count ((1 + extra_samplings) channels), ignoring sizeof(uint16_t), so it accepted a buffer half the required size. The samples are then stored through the uint16_t data->buffer by Wrap_MXC_ADC_GetData(), which writes two bytes per sample and advances the pointer by one uint16_t: in adc_max32_start_channel() for synchronous reads, and in adc_max32_isr() for asynchronous ones. A sequence selecting two channels with a two-byte buffer, for example, passes the check and has its second sample written past the end of the buffer. On a build with CONFIG_USERSPACE, adc_read() and adc_read_async() are system calls. The handler in drivers/adc/adc_handlers.c copies the sequence in from user memory, verifies only that [buffer, buffer + buffer_size) is writable by the calling thread, and rejects a user-supplied options->callback; it deliberately leaves the size arithmetic to the driver. A user-mode thread that has been granted access to a MAX32 ADC device object therefore fully controls channels, buffer, buffer_size and options->extra_samplings, and can make the driver write twice as many bytes as its buffer holds. Because the check scales with extra_samplings, the overrun equals the length of the buffer itself, up to channels * 65536 bytes past its end, since the sample pointer is only rewound on a repeat sampling, never on the extra samplings of a sequence. The resulting stores are performed by the driver in kernel mode (in the system call itself, the ADC context timer, or the ADC interrupt handler for asynchronous reads), where the MPU does not restrict the thread's memory domain, so the write walks linearly out of the user partition and into adjacent memory such as other partitions, kernel data or thread stacks. The impact is kernel-memory corruption of attacker-chosen length at an attacker-chosen offset, a plausible privilege-escalation and denial-of-service primitive from an unprivileged user-mode thread. Builds without CONFIG_USERSPACE are affected only as a caller-side robustness defect, since the application itself supplies the buffer. The fix replaces that check in start_read() with a call to the new shared helper adc_sequence_validate_buffer() in drivers/adc/adc_common.c, passing sizeof(uint16_t) as the sample size. The helper computes active_channels sizeof(uint16_t) (1 + extra_samplings) and returns -ENOMEM before any sampling is started.
Title Out-of-bounds write in the ADI MAX32 ADC driver due to incorrect adc_sequence buffer size validation
Weaknesses CWE-787
References
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

Subscriptions

Zephyrproject Zephyr
cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-09-30T15:28:20.886Z

Reserved: 2026-07-30T17:54:10.376Z

Link: CVE-2026-18414

cve-icon Vulnrichment

Updated: 2026-09-30T15:27:33.797Z

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-09-28T21:17:17.250

Modified: 2026-09-30T16:17:11.973

Link: CVE-2026-18414

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-28T22:30:08Z

Weaknesses