Zephyr RTOS EUVD-2026-43696

Requires the target device to be an Xtensa SoC built with BOTH CONFIG_XTENSA_MPU and CONFIG_USERSPACE, and the attacker must already be executing as an unprivileged user-mode thread on that device (PR:L, AV:L - local, authenticated at user level). The concrete trigger is passing a crafted (addr, size) to any syscall using k_usermode_from_copy/to_copy or k_usermode_string_copy such that size + alignment offset is near SIZE_MAX or ROUND_UP(size + offset) overflows the 32-bit address to 0, causing the MPU probe loop to run zero iterations. Limiting factors that reduce real-world exposure: it does not apply to non-Xtensa builds or Xtensa builds without MPU userspace, no remote vector exists (local thread execution is a prerequisite), and it depends on the specific compile-time configuration rather than a default. The string path (arch_user_string_nlen) is notably easier to reach because it has no syscall-layer overflow guard at all.

The CVSS 3.1 vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.8 High) is internally consistent with the description: this requires local code execution as an unprivileged user-mode thread (AV:L, PR:L) with low complexity and no user interaction, and yields full confidentiality, integrity, and availability impact through arbitrary kernel memory read/write. There is no EPSS score, KEV entry, or POC in the provided data, so exploitation is theoretical-but-credible rather than demonstrated - no public exploit identified at time of analysis. The realistic priority is moderated by a narrow precondition: it only affects Xtensa SoCs specifically compiled with both CONFIG_XTENSA_MPU and CONFIG_USERSPACE, a niche embedded configuration, so the population of exposed devices is far smaller than Zephyr's overall footprint. For teams actually running that configuration, however, this is a genuine userspace-isolation bypass that defeats the primary security boundary and should be patched promptly; for everyone else it is not applicable. No signals conflict here - the vector, description, and patch all agree.

An attacker who can run an unprivileged user-mode thread on an affected Xtensa device - for example via a compromised or malicious application partition - invokes any syscall that copies a user buffer (k_usermode_from_copy/to_copy or a string syscall) with a crafted (addr, size) pair whose rounded extent overflows the 32-bit address space to zero. Validation returns 'permitted' without probing any MPU region, so the kernel then reads attacker-chosen kernel memory (information disclosure) or, with write=1, overwrites kernel or other-partition memory (corruption), which can be leveraged into privilege escalation or denial of service. No public POC is available, but exploitation is low-complexity given local code execution.