Zephyr RTOS CVE-2026-10635

Exploitation requires Zephyr v4.4.0 compiled for an Xtensa target with both CONFIG_USERSPACE=y and CONFIG_XTENSA_MMU=y in the build configuration; the Xtensa MPU path is unaffected. The attacker must already possess privileged kernel/supervisor execution context - k_mem_domain_deinit() is not exposed as a system call and cannot be invoked by unprivileged user threads. Remote exploitation is not possible. The triggering sequence requires first calling k_mem_domain_deinit() (or an arch_mem_domain_deinit() caller) to create the dangling list node, then triggering any arch_mem_map() or arch_mem_unmap() code path to traverse the stale entry. Exploitation is limited to: (1) Zephyr v4.4.0 only - the vulnerable feature did not exist in prior releases; (2) Xtensa MMU path only; (3) high-privilege (kernel) code execution as a prerequisite; (4) dynamic memory domain lifecycle (create, use, destroy) must be exercised at runtime.

The provided CVSS 3.1 vector (AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:H, score 6.3) correctly reflects the local, high-privilege access requirement - k_mem_domain_deinit is callable only from privileged kernel/supervisor context and is not exposed as a syscall to unprivileged user threads. This substantially limits the attack surface in a typical Zephyr deployment: an attacker must already have kernel-level code execution to reach the vulnerable path. EPSS data was not provided, and the absence of KEV listing and public POC suggests no observed in-the-wild exploitation at time of analysis. The I:H and A:H ratings are appropriate given that successful exploitation can silently corrupt page-table mappings (degrading userspace isolation) or crash the kernel via a fatal MMU exception (denial of service in an embedded/IoT context where crash recovery may be unavailable). The C:L rating acknowledges potential confidentiality loss if userspace memory isolation is undermined. No CVSS/description conflict is present - both agree on the local, privileged nature of the flaw. Real-world priority is moderate-to-high for Zephyr v4.4.0 deployments using Xtensa/MMU with dynamic memory domains, but low or irrelevant for deployments on other architectures, using the MPU path, or not enabling CONFIG_USERSPACE.

A privileged kernel component (e.g., a kernel module or compromised driver) calls k_mem_domain_deinit() on an active memory domain, tearing down its page tables while leaving its node in xtensa_domain_list. A concurrent or subsequent kernel thread then invokes a memory-mapping operation (e.g., demand paging or k_mem_map()), which traverses the stale list entry and dereferences the now-NULL domain->arch.ptables pointer, crashing the Zephyr kernel with a fatal MMU exception. In a more targeted scenario, if the original k_mem_domain storage is freed and then reallocated for attacker-controlled data, the ptables pointer becomes a controlled value that l2_page_table_map writes through during the page-table walk, potentially redirecting virtual-to-physical mappings and breaking userspace process isolation.