Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain unprivileged user-mode thread with MAX32 ADC device grant
-
DeliveryCall adc_read with undersized buffer and large extra_samplings
-
ExploitPass flawed sample-count vs byte-count check in start_read()
-
ExecutionDriver writes 2 bytes/sample past buffer in kernel mode
-
PersistCorrupt adjacent kernel data or thread stacks
-
ImpactEscalate privilege or crash system (DoS)
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Bounds checking, write limits
MITRE ATT&CK
2 techniques across 2 tactics: Execution, Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires a Zephyr build compiled with CONFIG_USERSPACE running on ADI MAX32 hardware using the adc_max32 driver, AND a user-mode thread that has already been granted access to a MAX32 ADC device object; only then can the attacker control channels, buffer, buffer_size, and options->extra_samplings to overflow. Exploitation is local only (AV:L) and low-privileged (PR:L) - it does not work remotely. Builds without CONFIG_USERSPACE are not remotely/cross-privilege exploitable: the application itself supplies the buffer, reducing the issue to a caller-side robustness defect. No user interaction beyond the attacker's own syscall is needed. |
| Impact | This is a genuine local privilege-escalation/DoS primitive rather than an inflated high-CVSS score, but its real-world risk is tightly gated by deployment conditions. The 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: a low-privileged user-mode thread that already holds a device-object grant to a MAX32 ADC can trigger an attacker-controlled-length, attacker-controlled-offset out-of-bounds write in kernel mode where the MPU does not constrain it. The C:H/I:H/A:H ratings are justified because arbitrary kernel-memory corruption is a plausible path to full compromise (priv-esc) and to crashing the system (DoS). Crucially, the CVSS reflects the CONFIG_USERSPACE build; the vendor advisory itself notes builds WITHOUT CONFIG_USERSPACE are affected only as a caller-side robustness defect (the application supplies its own buffer), so severity is highly configuration-dependent. There is no EPSS score, no CISA KEV listing, and no public exploit provided in the input - so no public exploit is identified at time of analysis and there is no evidence of active exploitation. Given local-only access, a required prior device grant, and the MAX32-specific + USERSPACE-specific trigger, this is a lower-urgency patch-on-cycle item despite the 7.8 score. |
| Exploit ScenarioDerived | On a Zephyr build with CONFIG_USERSPACE targeting ADI MAX32 hardware, an unprivileged user-mode thread that has been granted access to a MAX32 ADC device object calls adc_read()/adc_read_async() with two channels and a two-byte buffer plus a large extra_samplings value. The undersized-buffer check in start_read() passes, and the driver writes samples through the uint16_t buffer in kernel mode, walking linearly past the user partition into adjacent kernel data or thread stacks. No public exploit code is identified at time of analysis; local low-privilege access and a pre-existing ADC device grant are required. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 28, 2026
An insufficient buffer-size validation defect in Zephyr RTOS's ADI MAX32 ADC driver (drivers/adc/adc_max32.c) allows a local, low-privileged user-mode thread to write up to twice the length of its supplied buffer into kernel memory, producing attacker-controlled out-of-bounds writes at an attacker-chosen offset. Exploitation requires a build compiled with CONFIG_USERSPACE running on ADI MAX32 hardware where the calling thread has already been granted access to a MAX32 ADC device object; on such a build the attacker fully controls channels, buffer, buffer_size and options->extra_samplings, and the resulting corruption of adjacent memory, kernel data or thread stacks is a plausible local privilege-escalation and denial-of-service primitive (CVSS 7.8, AV:L/PR:L). The flaw is not remotely exploitable, and builds without CONFIG_USERSPACE are reduced to a caller-side robustness defect since the application supplies its own buffer; no public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV).
RemediationAI
Apply the upstream fix, which replaces the incorrect sample-count comparison in start_read() with a call to adc_sequence_validate_buffer() (passing sizeof(uint16_t)) in drivers/adc/adc_common.c, so the sequence is rejected with -ENOMEM before sampling begins; the relevant commits are 9338c518bf2b6a396f166d4dbe9985ce7e44379c and 3bda971a52ddbbec28f6fcfe3b006d34e8b9e5a9, and the vendor advisory is https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-ghm4-78mm-8v2c. Patch status is best described as patch available per vendor advisory with an upstream fix available (commit-level); a specific released Zephyr version containing the fix was not independently confirmed from the provided data, so verify that the adc_sequence_validate_buffer() helper and the updated adc_max32.c are present in the revision you build. Where patching is not immediately possible, the most effective compensating control is to avoid granting user-mode threads access to MAX32 ADC device objects (remove the ADC device from userspace device access lists / do not call the userspace access-granting API for it); the trade-off is that user-mode applications can no longer perform ADC reads and must move ADC handling into a trusted supervisor-mode thread, which narrows attack surface but reduces the isolation benefits of the userspace design. Disabling CONFIG_USERSPACE removes the cross-privilege escalation path entirely, at the cost of losing memory-domain isolation for all user threads, but note this leaves the underlying out-of-bounds write as a caller-side robustness bug that a buggy application could still trigger against itself. Additionally, ADC callers should ensure buffers are sized as (active_channels * sizeof(uint16_t) * (1 + extra_samplings)) bytes as a defence-in-depth measure until the patched helper is deployed.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The ADC API in Zephyr documents a strict driver contract for struct adc_sequence: the buffer_size field is a byte count, and each driver must reject a sequence whose destination buffer is too small. The ADI MAX32 driver violated this in start_read(), comparing buffer_size against a pure sample count ((1 + extra_samplings) * channels) and ignoring sizeof(uint16_t), so it accepted buffers only half the size actually required. Samples are then stored through the uint16_t *data->buffer pointer by Wrap_MXC_ADC_GetData(), which writes two bytes per sample and advances by one uint16_t, both in adc_max32_start_channel() for synchronous reads and in adc_max32_isr() for asynchronous ones. Because extra_samplings scales the faulty check but the sample pointer is never rewound for extra samplings, the overrun can reach channels * 65536 bytes past the end of the buffer. Under CONFIG_USERSPACE, adc_read() and adc_read_async() are system calls: drivers/adc/adc_handlers.c copies the sequence in from user memory, validates only that [buffer, buffer + buffer_size) is writable by the calling thread, and rejects a user-supplied options->callback, deliberately delegating size arithmetic to the driver. The out-of-bounds stores execute in kernel mode (in the syscall itself, in the ADC context timer, or in the ADC ISR), where the MPU does not constrain the thread's memory domain, so the write walks linearly out of the user partition into adjacent partitions, kernel data or thread stacks. The root cause class is CWE-787 (out-of-bounds write) arising from a byte-versus-element unit mismatch in the length check. The upstream fix introduces a shared helper, adc_sequence_validate_buffer(), in drivers/adc/adc_common.c that computes active_channels * sizeof(uint16_t) * (1 + extra_samplings) and returns -ENOMEM before any sampling starts; adc_max32.c's start_read() now calls it.
Know when Zephyr gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Local user-mode thread with a pre-existing ADC device grant (PR:L, AV:L, AC:L) drives a kernel-mode arbitrary-length OOB write enabling priv-esc and DoS (C/I/A:H); scope unchanged as corruption stays within the same OS.
Primary rating from Vendor (zephyr).
CVSS VectorVendor: zephyr
DescriptionCVE.org
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.
Technical POC Analysis
CWE-787 (out-of-bounds write), a byte-versus-sample-count unit mismatch in startread() in drivers/adc/adcmax32.c.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
A memory-corruption defect in the Zephyr RTOS ADI MAX32 analog-to-digital converter driver allows a low-privileged local thread to write past the end of a caller-supplied buffer, potentially corrupting kernel data or thread stacks on affected devices. Only products built for ADI MAX32 hardware with user-space isolation enabled (CONFIG_USERSPACE) and that already expose a MAX32 ADC device object to the calling thread are exposed, and the same defect can be used to crash or destabilize a device even where privilege escalation is not achievable. Leadership should care because affected embedded products carry a local privilege-escalation and denial-of-service risk on deployed hardware, requiring a coordinated firmware rebuild and field-update cycle; no public exploit code was identified at time of analysis and the flaw is not remotely exploitable.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
Memory corruption occurs when a program writes data beyond the boundaries of allocated memory regions or accesses memory in unintended ways, violating the integrity of the process's address space.
Potential off-by-one buffer overflow vulnerability in the Zephyr fuse file system. Rated critical severity (CVSS 10.0),
An out-of-bounds write in the Zephyr RTOS DNS resolver (dns_unpack_name()) lets a crafted DNS response corrupt memory on
Possible variant of CVE-2021-3434 in function le_ecred_reconf_req. Rated critical severity (CVSS 9.8), this vulnerabilit
Unchecked user input length in /subsys/net/l2/wifi/wifi_shell.c can cause buffer overflows. Rated critical severity (CVS
Potential buffer overflow vulnerability in the Zephyr CAN bus subsystem. Rated critical severity (CVSS 9.8), this vulner
Integer Underflow in 6LoWPAN IPHC Header Uncompression in Zephyr. Rated critical severity (CVSS 9.8), this vulnerability
Buffer overflow in Zephyr USB DFU DNLOAD. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable
DOS: Incorrect 802154 Frame Validation for Omitted Source / Dest Addresses. Rated critical severity (CVSS 9.8), this vul
zephyr-rtos version 1.12.0 contains a NULL base pointer reference vulnerability in sys_ring_buf_put(), sys_ring_buf_get(
Potential buffer overflow vulnerabilities n the Zephyr Bluetooth subsystem. Rated critical severity (CVSS 9.6), this vul
The documentation specifies that the BT_GATT_PERM_READ_LESC and BT_GATT_PERM_WRITE_LESC defines for a Bluetooth characte
Potential buffer overflows in the Bluetooth subsystem due to asserts being disabled in /subsys/bluetooth/host/hci_core.c
EUVD-2026-88472
NVD
CVE.org
EPSS
Vulnrichment
GitHub
Exploit-DB