CVE-2026-10635
Description
In Zephyr v4.4.0 on Xtensa MMU, a missing list removal on domain deinitialization leaves a dangling pointer, enabling use-after-free or NULL dereference during subsequent page-table walks.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
In Zephyr v4.4.0 on Xtensa MMU, a missing list removal on domain deinitialization leaves a dangling pointer, enabling use-after-free or NULL dereference during subsequent page-table walks.
Vulnerability
In Zephyr v4.4.0 on Xtensa targets with CONFIG_USERSPACE and CONFIG_XTENSA_MMU enabled, the page-table code in arch/xtensa/core/ptables.c maintains a global linked list (xtensa_domain_list) of active memory domains. When a domain is destroyed via k_mem_domain_deinit() -> arch_mem_domain_deinit(), the page tables are torn down and domain->arch.ptables is set to NULL, but the domain's list node is not removed from xtensa_domain_list. This leaves a dangling pointer to the caller-owned struct k_mem_domain, which may later be freed or reused [1][2].
Exploitation
An attacker must have local kernel/supervisor privilege to call k_mem_domain_deinit() (this function is not a syscall and is not reachable from unprivileged user threads or remotely). Once a domain is deinitialized, any subsequent arch_mem_map() or arch_mem_unmap() operation — widely invoked by kernel memory-mapping and demand-paging code — traverses the stale list node. The code dereferences domain->ptables, which is NULL or points into freed/reused memory [1].
Impact
At minimum, a NULL pointer dereference triggers a fatal MMU exception, causing a denial of service. If the k_mem_domain storage has been freed or reused, the use-after-free allows a stale or attacker-controlled ptables value to be dereferenced and written through during the page-table walk. Specifically, l2_page_table_map writes to l1_table[...] and l2_table[...], and xtensa_mmu_compute_domain_regs writes into the domain struct and the L1 table. This yields page-table memory corruption that can undermine userspace isolation [1].
Mitigation
The vulnerability is fixed in commit 33d43d09337119fc6084b4ab545f9267839973f6 by adding a sys_slist_find_and_remove() call in arch_mem_domain_deinit() [2]. The fix has been merged into Zephyr's main branch. Users should update to a version that includes this commit; a projected fixed release has not been formally announced [1]. No workaround is available. The Xtensa MPU path is not affected [1].
AI Insight generated on Jun 16, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2(expand)+ 1 more
- (no CPE)
- (no CPE)range: <= v4.4.0
Patches
233d43d093371xtensa: ptables: fix dangling memory domains
1 file changed · +2 −0
arch/xtensa/core/ptables.c+2 −0 modified@@ -1379,6 +1379,8 @@ int arch_mem_domain_deinit(struct k_mem_domain *domain) domain->arch.ptables = NULL; + sys_slist_find_and_remove(&xtensa_domain_list, &domain->arch.node); + k_spin_unlock(&xtensa_mmu_lock, key); K_SPINLOCK(&xtensa_counter_lock) {
0936d76cdf0cxtensa: ptables: fix dangling memory domains
1 file changed · +2 −0
arch/xtensa/core/ptables.c+2 −0 modified@@ -1379,6 +1379,8 @@ int arch_mem_domain_deinit(struct k_mem_domain *domain) domain->arch.ptables = NULL; + sys_slist_find_and_remove(&xtensa_domain_list, &domain->arch.node); + k_spin_unlock(&xtensa_mmu_lock, key); K_SPINLOCK(&xtensa_counter_lock) {
Vulnerability mechanics
Root cause
"Missing list-removal in arch_mem_domain_deinit() leaves a deinitialized memory domain's node dangling in the global xtensa_domain_list, causing NULL-pointer dereference or use-after-free on subsequent page-table walks."
Attack vector
An attacker with privileged kernel/supervisor code execution calls `k_mem_domain_deinit()` on a memory domain, which invokes `arch_mem_domain_deinit()` [ref_id=1]. The domain's node remains linked in `xtensa_domain_list` after deinitialization. Any subsequent `arch_mem_map()` or `arch_mem_unmap()` operation — widely invoked by kernel memory-mapping and demand-paging code — traverses the stale list node and dereferences `domain->ptables`, which is NULL or points to freed/reused memory [ref_id=1]. This yields at minimum a NULL-pointer dereference (denial of service), and if the `k_mem_domain` storage has been freed or reused, a use-after-free where a stale/controlled `ptables` value is written through during the page-table walk, corrupting page tables and undermining userspace isolation [ref_id=1]. The vulnerable path is reachable only from privileged kernel/supervisor code; `k_mem_domain_deinit` is not a syscall and is not reachable from unprivileged user threads or remotely [ref_id=1].
Affected code
The bug is in `arch/xtensa/core/ptables.c` in the `arch_mem_domain_deinit()` function. The function tears down page tables and sets `domain->arch.ptables = NULL` but does not remove the domain's embedded list node from the global `xtensa_domain_list` [ref_id=1]. The list is traversed by `__arch_mem_map()` (lines 669-682) and `__arch_mem_unmap()` (lines 843-848), which dereference `domain->ptables` and call `l2_page_table_map`/`l2_page_table_unmap` and `xtensa_mmu_compute_domain_regs` on the stale entry [ref_id=1].
What the fix does
Both patches [patch_id=6140413] [patch_id=6140415] add a single line to `arch_mem_domain_deinit()` in `arch/xtensa/core/ptables.c`: `sys_slist_find_and_remove(&xtensa_domain_list, &domain->arch.node);` [patch_id=6140413]. This call removes the domain's embedded list node from the global `xtensa_domain_list` after the page tables have been torn down and before `domain->arch.ptables` is set to NULL. By unlinking the node, subsequent traversals of `xtensa_domain_list` during `arch_mem_map()`/`arch_mem_unmap()` will no longer encounter the deinitialized domain, preventing both the NULL-pointer dereference and the use-after-free condition [ref_id=1].
Preconditions
- configThe target must be an Xtensa SoC with CONFIG_USERSPACE and CONFIG_XTENSA_MMU enabled (which selects ARCH_MEM_DOMAIN_SUPPORTS_DEINIT)
- authThe attacker must have privileged kernel/supervisor code execution; k_mem_domain_deinit is not a syscall and is not reachable from unprivileged user threads
- inputA memory domain must be deinitialized via k_mem_domain_deinit() while its k_mem_domain storage may later be freed or reused
Reproduction
No public exploit or PoC is included in the bundle.
Generated on Jun 16, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2News mentions
0No linked articles in our index yet.