CVE-2026-79979: Stale TLB entries after demand-paging page-out let arm64 user threads access reused physical frames

Published Oct 23, 2026
·
Updated

The arm64 MMU backend invalidates a single virtual address from the TLB with invalidatetlbpage() in arch/arm64/core/mmu.c, which issued TLBI VAE1{IS} with an operand of virt >> 12. That operand encodes the ASID in bits [63:48], so the invalidation only ever matched ASID 0 (the kernel page tables) and global entries. Memory domains, however, are allocated ASIDs starting at 1 in archmemdomaininit(), and every domain-private leaf created by privatemap() is mapped with MTNG, i.e. non-global. A domain's cached translation therefore survived the invalidation.

All callers of invalidatetlbpage() are demand-paging paths. When the eviction algorithm reclaims a frame, pageframepreparelocked() in kernel/mmu.c calls archmempageout(), which marks the kernel leaf invalid, propagates the invalid descriptor into every domain via syncdomains(), and then flushes only ASID 0. dopagefault() immediately reuses the very same page frame for the incoming mapping through archmempagein(). A user thread that had already touched the evicted page — a kmempartition added with archmemdomainpartitionadd(), or its own stack mapped by mapthreadstack() — retains a valid EL0 read/write translation to that physical frame under its own ASID.

Unprivileged code running in a user thread can drive memory pressure to force eviction and then keep accessing the stale address, obtaining read and write access to whatever the kernel subsequently placed in that frame: supervisor data, another memory domain's partition, or another thread's stack. This defeats the isolation that CONFIGUSERSPACE is meant to enforce, allowing information disclosure and memory corruption up to full compromise of the system.

The fix switches the implementation to TLBI VAAE1{IS}, which matches every ASID and both global and non-global entries, so no domain-tagged translation survives a page out, dirty-bit update or access-flag clear. Exploitation requires an arm64 build with both CONFIGUSERSPACE and CONFIGDEMANDPAGING enabled, an active backing store, and at least one demand-paged page that is also privately mapped into a user memory domain. The same commit additionally stops globalizetable() from stripping EL0 permission and non-global attributes off domain-private leaves during paging synchronization, which previously caused user threads to lose access to their own partitions and stacks.

Affected Software

1 affected component
Zephyr Project Zephyr

Event History

Oct 23, 2026
CVE Published
via MITRE·07:56 PM
Data Sourced
via MITRE·07:56 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which deployments are exposed to this issue?

The issue affects arm64 systems using demand paging together with memory domains that receive non-global, domain-private mappings. User thread stacks mapped through map_thread_stack() and partitions added through arch_mem_domain_partition_add() are identified as relevant mappings.

2

What does an attacker need to do to exploit it?

An attacker needs local, low-privilege execution in a user thread and must have previously accessed a page that is later evicted. Exploitation also depends on the reclaimed physical frame being immediately reused for another mapping while the thread retains its stale translation, making the attack complexity high.

3

What access could stale translations provide?

A user thread can retain an EL0 read/write translation to a physical frame after its original mapping has been invalidated and the frame has been reused. This can expose the contents of, or permit modification of, the new mapping backed by that reused frame.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203