CVE-2026-12634 in Zephyr
Summary
by MITRE • 08/20/2026
The NVS backend of the Zephyr settings subsystem (subsys/settings/src/settings_nvs.c) reads stored setting-name entries into fixed 74-byte stack buffers and NUL-terminates them with buf[rc] = '\0', where rc is the return value of nvs_read(). Per its contract, nvs_read() returns the full stored entry length (wlk_ate.len), which can exceed the supplied buffer length — only MIN(len, stored_len) bytes are actually copied, but the return value may be much larger, bounded only by the NVS sector size. Three sites (settings_nvs_cache_match(), settings_nvs_load(), and settings_nvs_save()) used this value directly as the NUL index without clamping, so an oversized stored name entry causes a single \0 byte to be written past the end of the stack buffer at an attacker-influenced offset (CWE-787).
The oversized entry cannot arise through the normal settings API, where names are bounded by SETTINGS_MAX_NAME_LEN. It requires an actor able to write the flash that backs the settings partition — a co-resident or untrusted component sharing the flash device, a malicious settings image/restore, or offline/physical flash access (a shared-flash threat model). The malformed entry is parsed when settings_load() runs at boot or subsystem init, or during settings_save().
The out-of-bounds write is a single NUL byte at an offset equal to the crafted entry length (up to the NVS sector size), so the practical impact is a crash or denial of service and limited stack corruption rather than reliable code execution. There is no confidentiality impact, and the path is not reachable from the network through the ordinary settings interface. The fix skips any entry whose nvs_read() length is greater than or equal to the buffer size before performing the NUL store.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The Zephyr real-time operating system contains a critical memory safety vulnerability within its Non-Volatile Storage backend, specifically located in the settings subsystem source file subsys/settings/src/settings_nvs.c. This flaw stems from an improper handling of buffer boundaries during the reading and processing of stored setting-name entries. The code utilizes fixed-size stack buffers with a capacity of seventy-four bytes to hold these names. When retrieving data via the nvs_read function, the implementation relies on the return value of that function to determine where to place a null terminator byte using the expression buf[rc] = '\0'. However, there is a fundamental mismatch between the buffer size and the length reported by the storage layer. The nvs_read function returns the full logical length of the stored entry as defined in the flash wear-leveling area structure, which can significantly exceed the seventy-four-byte limit imposed on the stack buffer. While only up to seventy-four bytes are actually copied into the destination array due internal clamping logic within the read operation, the return value reflects the original, potentially much larger length of the data stored in non-volatile memory.
This discrepancy leads directly to a heap-based or stack-based out-of-bounds write vulnerability classified under CWE-787 Out-of-Bounds Write. Three specific functions within the subsystem settings_nvs_cache_match, settings_nvs_load, and settings_nvs_save are affected by this logic error because they all utilize the unclamped return value from nvs_read as an index for writing the null terminator. Consequently, if a stored setting name entry has a length greater than seventy-four bytes but less than or equal to the NVS sector size limit, the code will write a single zero byte at an offset corresponding to that excessive length. This operation writes past the end of the allocated stack buffer into adjacent memory regions on the call stack. The magnitude of this overflow is determined by the crafted entry length, potentially reaching offsets bounded only by the physical constraints of the NVS sector size rather than the immediate local variable boundaries.
The exploitation scenario for this vulnerability requires a specific threat model that goes beyond standard remote network attacks or unprivileged user interactions. Because normal application programming interfaces enforce a maximum name length defined by SETTINGS_MAX_NAME_LEN, it is impossible to trigger this condition through legitimate API usage. Instead, an attacker must possess the ability to write directly to the flash memory backing the settings partition. This could be achieved through several vectors including co-resident untrusted components sharing the same flash device, injection of a malicious settings image or restore file during system updates, or physical access allowing offline modification of the storage medium. Once such malformed data is present in the non-volatile storage, it becomes active when the operating system initializes the settings subsystem at boot time or whenever settings are loaded or saved by an application process.
The operational impact of this vulnerability is primarily centered on availability and stability rather than confidentiality or reliable remote code execution. The out-of-bounds write involves a single null byte, which limits its ability to reliably overwrite critical control data such as return addresses or function pointers required for arbitrary code execution. However, the corruption of stack memory can still lead to severe consequences including application crashes, denial of service conditions where the system becomes unresponsive, and unpredictable behavior due to corrupted local variables or saved register states. This aligns with typical outcomes observed in CWE-120 Buffer Copy without Checking Size of Input Classic buffer overflow scenarios where partial overflows occur but do not provide full control flow hijacking capabilities. The attack path is classified under ATT&CK techniques related to persistence through system configuration changes and local privilege escalation via memory corruption, although the latter is limited by the nature of the write operation.
Mitigation strategies focus on enforcing strict bounds checking before performing any writes that depend on external input lengths. The primary defense involves validating the length returned from storage read operations against the size of the destination buffer prior to accessing array indices derived from that length. In this specific case, the fix implements a check to skip processing any entry where the nvs_read return value is greater than or equal to the available buffer size. This prevents the out-of-bounds write by ensuring that the null terminator is only written within the allocated memory space. Developers integrating Zephyr should ensure they are running patched versions of the settings subsystem and consider implementing additional hardening measures such as stack canaries and address space layout randomization where supported to mitigate potential exploitation attempts even if other vulnerabilities exist in adjacent code paths.