Stale TLB entries after demand-paging page-out let arm64 user threads access reused physical frames
CVSS score
7.8
EPSS probability
—
Risk score
0.8
Published
2 h ago
Etkilenen ürün ve sürüm için yayımlanan güvenlik güncellemesini uygulayın.
Impact on My Inventory
Only the personal products you have added to your account are assessed; an organisation's inventory does not appear here.
Checking session…
Vulnerability description
DayBreach AI Explanation
Verified against sourcesSources read
1
Source agreement
Tam uyum
Evidence confidence
%55
Short explanation
An issue in the arm64 MMU backend demand-paging invalidation mechanism in Zephyr allows stale TLB entries to let user threads access reused physical frames, leading to potential information disclosure and memory corruption.
This vulnerability defeats the isolation enforced by CONFIG_USERSPACE, allowing unprivileged code to gain unauthorized access to sensitive data up to full compromise of the system.
What should be done?
- Follow the vendor advisory
- Apply the patch commit
- Review CONFIG_USERSPACE and CONFIG_DEMAND_PAGING configurations
Chain of evidence and sources
Söz konusu zafiyet, zephyr ürününün 4.3.0 ile 4.5.0 sürümleri arasındaki arm64 yapılandırmalarını etkilemektedir.
Güvenlik açığı için CVSS taban puanı 7.8 olarak belirlenmiştir ve ciddiyet seviyesi yüksektir.
Show the technical text from the sources
The arm64 MMU backend invalidates a single virtual address from the TLB with invalidate_tlb_page() 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 arch_mem_domain_init(), and every domain-private leaf created by private_map() is mapped with MT_NG, i.e. non-global. A domain's cached translation therefore survived the invalidation. All callers of invalidate_tlb_page() are demand-paging paths. When the eviction algorithm reclaims a frame, page_frame_prepare_locked() in kernel/mmu.c calls arch_mem_page_out(), which marks the kernel leaf invalid, propagates the invalid descriptor into every domain via sync_domains(), and then flushes only ASID 0. do_page_fault() immediately reuses the very same page frame for the incoming mapping through arch_mem_page_in(). A user thread that had already touched the evicted page — a k_mem_partition added with arch_mem_domain_partition_add(), or its own stack mapped by map_thread_stack() — 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 CONFIG_USERSPACE 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 CONFIG_USERSPACE and CONFIG_DEMAND_PAGING 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 globalize_table() 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.
CVSS vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
CWE: CWE-416
This explanation was compiled automatically from the source records. Scores, active exploitation, patch and exploit status come straight from the sources.
IMPACT: Affected Products and Software
Affected Products
The following products are affected by CVE-2026-79979 vulnerability. Where our threat engine knows the exact affected versions, they are listed below.
| ID | VENDOR | PRODUCT | ACTION |
|---|---|---|---|
| 1 | zephyrproject | zephyr | View |
RED HAT CSAF/VEX: Product Impact Check
SCORING: CVSS from Multiple Sources
CVSS Scores
The Common Vulnerability Scoring System is a standardised framework for assessing the severity of vulnerabilities in software and systems. We collect and display CVSS scores from several sources for each CVE.
| SCORE | VERSION | SEVERITY | VECTOR | SOURCE |
|---|---|---|---|---|
| 7.8 | CVSS V3_1 | HIGH | CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H | CVE CNA |
| 7.8 | CVSS V31 | HIGH | CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H | NVD |
Patch and Remediation Guide
Solution & Remediation Advisory
2 doğrulanmış yama veya düzeltilmiş sürüm kanıtı bulundu.
Public exploit and active exploitation status
Verified exploit intelligence
No verified public PoC, exploit repository or Metasploit module has been found for this CVE yet.
Weakness Classification and Attack Patterns (CWE & CAPEC)
CWE - Common Weakness Enumeration
While CVE identifies specific instances of vulnerabilities, CWE categorises the common flaws or weaknesses that can lead to vulnerabilities. CVE-2026-79979 is associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification (CAPEC) stores attack patterns, which are descriptions of the common attributes and approaches employed by adversaries to exploit the CVE-2026-79979 weaknesses.
Attack Vector and Accessibility
Official Sources and Advisories
CVSS Vector Radar Chart
7.8 / 10Vulnerability Scoring Details
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:HYama doğrulandı
Weakness Type (CWE & CAPEC)
Similar Vulnerabilities
Get this vulnerability through the API
Affected products, version ranges, exploitation status and patch information in a single request, with a free key.
curl -H "x-api-key: $DAYBREACH_API_KEY" \ "https://api.daybreach.dev/api/v1/intel/cves/CVE-2026-79979"