dbcve.org
ZephyrOperating system · Zephyrproject

CVE-2026-10669

HIGH · 7.8 CVSS v3.1 Published 2026-07-14
Fix available
A fix is available. Upgrade to 4.5.0 or later.
See remediation →
80/100
Remediation priority · High
Zero-click 5 weeks old

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
On Xtensa SoCs built with CONFIG_XTENSA_MPU and CONFIG_USERSPACE, arch_buffer_validate() in arch/xtensa/core/mpu.c — the architecture hook that verifies a user-mode-supplied buffer is accessible to the calling user thread with the requested permission — defaulted its return value to 0 (access permitted) and only set a denial result inside its per-MPU-region probe loop. When the rounded extent of the buffer wraps the 32-bit address space (size + alignment offset near SIZE_MAX, or ROUND_UP(size + offset) overflowing to 0), the loop executes zero iterations and the function returns 0 = permitted without probing any MPU region. The syscall-layer pre-checks (K_SYSCALL_MEMORY_SIZE_CHECK / Z_DETECT_POINTER_OVERFLOW) only catch a raw addr+size wrap and do not cover the ROUND_UP-induced wrap, and the string path (arch_user_string_nlen -> arch_buffer_validate) has no syscall-layer guard at all. An unprivileged user-mode thread can therefore pass a crafted (addr, size) to any syscall that validates user buffers via k_usermode_from_copy/to_copy or k_usermode_string_copy and have validation succeed for memory it must not access; the kernel then reads from (disclosure) or, with write=1, writes to (corruption) attacker-chosen kernel or other-partition memory on the thread's behalf, enabling information disclosure, memory corruption, privilege escalation, and denial of service. Affected from v3.7.0 (when Xtensa MPU userspace support was added) through v4.4.0. The fix changes the default to -EINVAL (deny by default), adds an explicit size_add_overflow check, and sets the success value only after the full range has been validated.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

On Xtensa SoCs with CONFIG_XTENSA_MPU and CONFIG_USERSPACE enabled, the arch_buffer_validate() function incorrectly returns 0 (access permitted) by default. When a user-supplied buffer's rounded extent wraps the 32-bit address space, the MPU region validation loop executes zero iterations, causing the function to permit access without any actual validation. This allows unprivileged user threads to bypass memory access checks and read/write to arbitrary kernel or partition memory.

MitigationUpgrade Zephyr RTOS to v4.4.0 or later which contains the fix that changes the default return value to -EINVAL (deny by default), adds explicit size_add_overflow check, and sets success only after full range validation.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
ZephyrOperating system
Affected:>= 3.7.0, < 4.5.0

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Local
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify the target SoC architecture
    Check the hardware platform or SoC documentation, or inspect the build configuration (usually in .config or prj.conf) for Xtensa-specific defines
    Affected if The system uses an Xtensa-based SoC (e.g., ESP32 series)
  2. Verify CONFIG_XTENSA_MPU is enabled
    Inspect the kernel configuration file (typically .config or the generated devicetree) for the presence of CONFIG_XTENSA_MPU=y
    Affected if CONFIG_XTENSA_MPU is set to y in the build configuration
  3. Verify CONFIG_USERSPACE is enabled
    Inspect the kernel configuration file for the presence of CONFIG_USERSPACE=y or CONFIG_USERSPACE=m
    Affected if CONFIG_USERSPACE is enabled in the build configuration
  4. Determine the Zephyr RTOS version
    Check the Zephyr version in the project (usually found in version.h, west.yml, or the SDK/release notes) and compare against v4.4.0
    Affected if The Zephyr version is older than v4.4.0 (prior to the fix)
  5. Inspect arch_buffer_validate implementation
    If accessible, examine the arch_buffer_validate function source code in the Xtensa architecture layer to verify if it returns -EINVAL by default (fixed) or 0 (vulnerable)
    Affected if The function returns 0 (permit) as default rather than -EINVAL (deny) when no validation iterations occur

A user is affected if their system uses an Xtensa SoC with both CONFIG_XTENSA_MPU and CONFIG_USERSPACE enabled, and runs Zephyr RTOS versions prior to v4.4.0, where arch_buffer_validate permits access by default instead of denying.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 4.5.0 or later
Fixed in 4.5.0
Interim mitigation

Upgrade Zephyr RTOS to v4.4.0 or later which contains the fix that changes the default return value to -EINVAL (deny by default), adds explicit size_add_overflow check, and sets success only after full range validation.

Recommended fix High confidence

Zephyr RTOS v4.4.1 or later (or the corresponding stable branch)

  1. 1. Identify the current Zephyr RTOS version in use by checking the version tag or manifest file in the project.
  2. 2. Upgrade Zephyr RTOS to version v4.4.1 or later, as this version contains the fix for the arch_buffer_validate() vulnerability.
  3. 3. If using a downstream or fork of Zephyr, apply the equivalent patch: modify arch/xtensa/core/mpu.c to change the default return value of arch_buffer_validate() from 0 (permit) to -EINVAL (deny), add an explicit size_add_overflow check before the MPU region probe loop, and move the success return value to after the full range validation completes.
  4. 4. Rebuild the firmware with the updated Zephyr version or patched code.
  5. 5. Verify the build completes successfully and test the system's functionality.
Caveat Upgrade to v4.4.1 should be low-risk as this is a security fix in validation logic; however, any custom code relying on the incorrect permissive default behavior may need adjustment.

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Zephyr Scoped from the published advisory
  • Consultation4.0 h
  • Implementation3.0 h
  • Testing8.0 h
  • Review / QA3.0 h
18.0 hours of engineering $3,080
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $4,928.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-10669 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-10669 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data