CVE-2026-74524 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
riscv: mm: Fix out-of-bounds page-table walk during memory hot-remove
remove_pud_mapping() and remove_p4d_mapping() obtain a child table base with pud_offset(p4dp, 0) and p4d_offset(pgd, 0), then add the index for addr.
RISC-V folds page-table levels at runtime. When a level is folded, its offset helper returns the parent entry itself, but the index can still be nonzero. Adding it walks past the parent table. Sv48 folds P4D, while Sv39 folds both P4D and PUD, so memory hot-remove can descend into unrelated memory and pass an invalid page to __free_pages(). This can trigger:
kernel BUG at include/linux/mm.h:1810! VM_BUG_ON_PAGE(page_ref_count(page) == 0) arch_remove_memory+0x1e/0x5c try_remove_memory+0x15e/0x200 remove_memory+0x24/0x3c
Only add the index when the corresponding page-table level is enabled, matching p4d_offset() and pud_offset().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists in the riscv architecture implementation of the linux kernel's memory management subsystem where improper handling of page table walks during memory hot-remove operations leads to out-of-bounds access. The flaw occurs specifically in the remove_pud_mapping() and remove_p4d_mapping() functions which retrieve child table bases using pud_offset(p4dp, 0) and p4d_offset(pgd, 0) respectively, then proceed to add index values for address calculations without proper validation of page table level availability.
The root cause stems from the riscv architecture's dynamic page table level folding mechanism where certain page table levels may be collapsed at runtime based on the virtual memory configuration. When a level is folded, its offset helper functions return the parent entry directly rather than a separate child table, yet the index calculation still proceeds as if the level were active. This discrepancy becomes critical because sv48 architecture folds the p4d level while sv39 folds both p4d and pud levels, creating scenarios where memory hot-remove operations can traverse into unrelated memory regions.
The technical impact manifests when the system attempts to free pages during memory removal operations, specifically triggering a kernel BUG at include/linux/mm.h:1810 with the assertion VM_BUG_ON_PAGE(page_ref_count(page) == 0). This occurs because the invalid page pointer passed to __free_pages() results from walking past valid page table boundaries into memory that should not be accessible during the removal process. The call stack shows arch_remove_memory calling try_remove_memory which eventually leads to remove_memory, demonstrating the complete path of execution that exposes this vulnerability.
The operational consequences extend beyond simple kernel crashes as this vulnerability represents a critical memory safety issue that could potentially enable privilege escalation or denial of service attacks when exploited in controlled environments. This flaw directly relates to common weakness enumeration CWE-129 and aligns with attack techniques documented in the attack tactic and technique framework under memory corruption vulnerabilities. The fix requires conditional index addition only when corresponding page table levels are actually enabled, matching the behavior of existing p4d_offset() and pud_offset() functions that properly account for level availability.
This vulnerability demonstrates the complexity inherent in virtual memory management implementations where architectural optimizations like level folding must be carefully coordinated with memory management operations to prevent access violations. The mitigation strategy focuses on ensuring proper validation of page table level states before performing index-based calculations, establishing a defensive programming pattern that prevents out-of-bounds memory accesses during critical kernel operations such as memory hot-remove functionality. The solution essentially implements a runtime check that verifies whether specific page table levels are active before applying index offsets, thereby preventing the traversal into invalid memory regions and maintaining kernel stability during dynamic memory management operations.