Zephyr RTOS EUVD-2026-57070

Exploitation requires all of the following to be true simultaneously: (1) the Zephyr device runs on Xtensa architecture - the vulnerable code path (tgt != NULL branch in llext_link_plt()) is specific to Xtensa relocatable ELF processing and is not triggered on other Zephyr-supported architectures; (2) the llext subsystem is compiled in (CONFIG_LLEXT=y in Kconfig); (3) the attacker can write a crafted ELF file to storage locations accessible to the llext loader - llext documentation states it is designed to accept extensions of untrusted origin, so this may be an intended workflow; (4) the application invokes llext_load() on attacker-influenced input at runtime. The CVSS PR:L metric confirms low-privilege access is sufficient. Exploitation is further limited by the fact that the write value is not fully arbitrary - it is the resolved symbol address - making reliable memory corruption into useful code execution non-trivial. The vulnerability is completely absent on non-Xtensa builds and in builds where CONFIG_LLEXT=n.

The vendor-supplied CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H, score 6.3) accurately captures the constrained attack surface: local access to writable extension storage is prerequisite, complexity is high because the write value is constrained to a resolved symbol address rather than a fully arbitrary value, and no confidentiality loss occurs. However, the S:U (Unchanged scope) rating warrants scrutiny - the description explicitly states 'sandbox-boundary escape for user-mode extensions' as an impact, which implies the user-mode extension sandbox boundary is crossed to affect supervisor context, a potential scope-change scenario. This analysis independently assesses scope as Changed (S:C), which would raise the effective severity. No EPSS score was included in the provided intelligence data, making probabilistic exploitation forecasting unavailable. The CVE is not listed in CISA KEV, and no POC or active exploitation has been identified. Real-world prioritization should weight architecture specificity (Xtensa-only), feature dependency (CONFIG_LLEXT=y required), and the non-trivial conversion of the OOB write into a reliable primitive - making this a meaningful but not urgent finding for most Zephyr deployments.

An attacker with low-privilege access to a Zephyr-based Xtensa device crafts a relocatable ELF extension containing a RELA entry with an r_offset value larger than the target section size, then writes it to extension storage accessible to the llext loader. When the Zephyr application calls llext_load() on the crafted extension, llext_link_plt() processes the malicious relocation entry and performs a supervisor-context out-of-bounds write before any extension code executes - potentially overwriting kernel data structures, function pointers, or security-critical metadata. Converting this write (constrained to a resolved symbol address value) into a reliable privilege escalation or persistent code execution primitive requires additional attacker effort and knowledge of the target memory layout, but the supervisor-context write location is attacker-influenced via r_offset.