CVE-2026-10635: Xtensa Memory Domain Use-After-Free in Zephyr RTOS

Technical summary

The Xtensa page-table code (arch/xtensa/core/ptables.c) maintains a global linked list, xtensa_domain_list, containing active memory domains via list nodes embedded in caller-owned k_mem_domain structures. When k_mem_domain_deinit() is called, the function tears down page tables and nulls domain->arch.ptables but omits removal of the domain's node from xtensa_domain_list. The deinitialized domain becomes a dangling pointer within the global list. Subsequent arch_mem_map() or arch_mem_unmap() operations traverse this stale node and dereference domain->ptables. If that memory has been freed or reused, the l2_page_table_map and xtensa_mmu_compute_domain_regs functions write to arbitrary kernel memory locations (L1 and L2 page tables, domain structure fields), corrupting page-table metadata and potentially breaking userspace isolation. The fix adds explicit list removal via sys_slist_find_and_remove() during domain deinitialization.

Business impact

For deployments using Zephyr on Xtensa targets with MMU and CONFIG_USERSPACE enabled, this vulnerability creates a window for kernel-level memory corruption following domain teardown. If memory domains are created and destroyed as part of normal operation (e.g., dynamic task lifecycle, privilege isolation features), the freed k_mem_domain storage can be reallocated or overwritten, allowing subsequent memory-mapping operations to corrupt page tables. This undermines the integrity of user/kernel isolation boundaries and can lead to privilege escalation or data corruption. Organizations relying on Zephyr's userspace protection for security-sensitive embedded systems face a medium-severity exposure.

Affected systems

Zephyr v4.4.0 and later versions prior to the fix on the main branch are affected. The vulnerability is specific to Xtensa architecture targets configured with CONFIG_USERSPACE and CONFIG_XTENSA_MMU enabled. The Xtensa MPU (memory protection unit) variant is not affected. Systems using other architectures (ARM, RISC-V, etc.) or Xtensa systems without MMU support are unaffected.

Exploitability

Exploitation requires privileged kernel code to call k_mem_domain_deinit() followed by a memory-mapping operation that traverses the stale list node. The vulnerability cannot be triggered directly by unprivileged user-space code or remote attackers. However, any kernel driver, thread, or subsystem that performs domain deinitialization and subsequent memory remapping within the same system lifecycle creates exposure. If an attacker has already achieved kernel-level code execution, this vulnerability can be leveraged to corrupt page tables and further elevate privileges or disable isolation. In typical embedded deployments, kernel code is trusted, reducing the threat model; however, systems with untrusted kernel-loaded modules or firmware updates face elevated risk.

Remediation

Apply the main-branch fix: add sys_slist_find_and_remove() to arch_mem_domain_deinit() to explicitly remove the domain's node from xtensa_domain_list before page-table teardown completes. This ensures the domain is no longer reachable via list traversal after deinitialization. Verify the patch version against the official Zephyr advisory to confirm the exact commit or release tag. For systems unable to upgrade immediately, restrict domain creation/destruction to initialization phases or implement a graceful shutdown procedure that drains all pending memory-mapping operations before tearing down domains.

Patch guidance

The official fix is available on the Zephyr main branch (verify exact commit hash and release version against the vendor advisory). Users should update to the patched version once released in a stable branch (e.g., v4.5.0 or later). Before upgrading, verify compatibility with your Xtensa toolchain, CONFIG_USERSPACE/CONFIG_XTENSA_MMU settings, and any out-of-tree drivers. Test the patched kernel thoroughly in a staging environment, especially any code paths that exercise k_mem_domain lifecycle operations. If an immediate patch is unavailable for your release series, contact the Zephyr security team for guidance on backports or workarounds.

Detection guidance

Monitor kernel logs for MMU exceptions, faults, or memory access violations correlated with k_mem_domain operations. On Xtensa targets, watch for CPU exceptions during arch_mem_map() or arch_mem_unmap() calls. Memory corruption signatures (e.g., unexpected page-table entries, corrupted domain structures) may appear in crash dumps or kernel memory inspections. Static code analysis tools can flag use-after-free patterns in list management; audit calls to k_mem_domain_deinit() to confirm list removal occurs. Dynamic debugging with kernel assertions enabled can catch dangling-pointer dereferences at runtime. If you control the system build, enable CONFIG_DEBUG_OBJECTS and related Kconfig options to catch memory-domain lifecycle issues earlier.

Why prioritize this

Although the CVSS score is 6.3 (medium), the actual risk depends on deployment architecture. Systems using Xtensa with MMU and CONFIG_USERSPACE for security-critical userspace isolation (e.g., trusted execution environments, multi-tenant embedded systems) should prioritize this patch. Systems where kernel and userspace are not strictly separated, or where Xtensa targets do not have MMU enabled, face lower risk. The requirement for privileged kernel code to trigger the vulnerability limits remote-attack surface, but post-compromise escalation and privilege-boundary violations warrant prompt remediation in security-sensitive deployments.

Risk score, explained

CVSS 6.3 (Medium) reflects moderate severity with constraints: a high-privilege actor (PR:H) on a local system (AV:L) with no user interaction (UI:N) can corrupt memory (I:H), cause denial of service (A:H), and partially compromise confidentiality (C:L). The score does not fully capture the context-dependent risk: in systems where CONFIG_USERSPACE isolation is critical to threat model, the impact rating would be higher; in systems without strict userspace isolation, the risk is lower. The vulnerability requires existing kernel-level compromise or trusted-code misuse to manifest; it is not independently exploitable from user space.

Frequently asked questions