CVE-2026-72043 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()
When hardware page table walker (PTW) is enabled on LoongArch, the CPU may set _PAGE_DIRTY directly in the page table entry during a write TLB miss, without going through the software TLB store handler. The software TLB store handler (tlbex.S:254) sets both _PAGE_DIRTY and_PAGE_MODIFIED together:
ori t0, t0, (_PAGE_VALID | _PAGE_DIRTY | _PAGE_MODIFIED)
Since hardware PTW only sets _PAGE_DIRTY, the software-only bit, i.e. _PAGE_MODIFIED is left unchanged. This creates a window where a PTE has _PAGE_DIRTY set (hardware knows the page is dirty) but _PAGE_MODIFIED clear (software is unaware).
When fork()/clone() triggers copy-on-write, __copy_present_ptes() calls pte_wrprotect(), which unconditionally clears both the _PAGE_WRITE and _PAGE_DIRTY bits:
pte_val(pte) &= ~(_PAGE_WRITE | _PAGE_DIRTY);
Since _PAGE_MODIFIED was never set, the dirtiness information is lost completely. Subsequently, when memory pressure triggers page reclaim, page_mkclean() / try_to_unmap() sees the page as clean (i.e. pte_dirty() returns false) and the page may be freed without writeback, causing data corruption.
Fix this by propagating the _PAGE_DIRTY bit to the _PAGE_MODIFIED bit in both pte_wrprotect() and pmd_wrprotect() before clearing writeable bits:
if (pte_val(pte) & _PAGE_DIRTY) pte_val(pte) |= _PAGE_MODIFIED;
The pmd_wrprotect() fix handles the CONFIG_TRANSPARENT_HUGEPAGE case, where pmd entries need the same treatment.
This ensures the software dirty tracking bit (checked by pte_dirty() and pmd_dirty(), which read both the _PAGE_DIRTY and _PAGE_MODIFIED bits) is preserved across fork COW write-protection.
The issue was found by the LTP madvise09 test case, which exercises page reclaim after "madvise(MADV_FREE), write and fork" operation sequence on private anonymous mappings.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability resides in the LoongArch architecture implementation within the Linux kernel where improper handling of dirty page tracking during write protection operations leads to potential data corruption. This flaw specifically manifests when hardware page table walkers are enabled, creating a discrepancy between hardware and software page table entry management. The core issue stems from the fact that hardware PTW can directly set _PAGE_DIRTY in page table entries during write TLB misses without invoking the software TLB store handler. The software handler typically sets both _PAGE_DIRTY and _PAGE_MODIFIED bits simultaneously through the instruction ori t0, t0, (_PAGE_VALID | _PAGE_DIRTY | _PAGE_MODIFIED) at line 254 of tlbex.S, but hardware PTW only sets _PAGE_DIRTY leaving _PAGE_MODIFIED unset.
This creates a critical window where page table entries contain the _PAGE_DIRTY bit indicating hardware awareness of dirty state while the software tracking bit _PAGE_MODIFIED remains cleared. The inconsistency becomes problematic during copy-on-write operations triggered by fork() or clone() system calls, when __copy_present_ptes() invokes pte_wrprotect() to clear both write and dirty bits unconditionally through pte_val(pte) &= ~(_PAGE_WRITE | _PAGE_DIRTY). Since _PAGE_MODIFIED was never set by the hardware path, this operation completely eliminates any record of the page's dirty status from software perspective. The vulnerability directly impacts memory management and data integrity because when page reclaim occurs under memory pressure, functions like page_mkclean() and try_to_unmap() evaluate page cleanliness using pte_dirty() which checks both _PAGE_DIRTY and _PAGE_MODIFIED bits. When these bits indicate a clean page, the system may prematurely free pages without proper writeback, resulting in data loss or corruption.
The fix implements a targeted solution that propagates the _PAGE_DIRTY bit to the _PAGE_MODIFIED bit before clearing write protection bits in both pte_wrprotect() and pmd_wrprotect() functions. This ensures that when pte_wrprotect() executes the operation of clearing write permissions, it first checks if _PAGE_DIRTY is set and then sets _PAGE_MODIFIED accordingly through the conditional statement if (pte_val(pte) & _PAGE_DIRTY) pte_val(pte) |= _PAGE_MODIFIED. The same logic applies to pmd_wrprotect() to address transparent huge page configurations where pmd entries require identical treatment. This approach aligns with common security practices for maintaining consistent memory state tracking and prevents information leakage between hardware and software memory management components.
The vulnerability demonstrates a classic case of inconsistent state management between hardware and software layers in memory virtualization, particularly affecting systems running on LoongArch architecture with hardware PTW enabled. The issue manifests primarily during fork operations with copy-on-write semantics when combined with memory pressure scenarios that trigger page reclamation. The LTP madvise09 test case specifically exercises this vulnerability path by performing "madvise(MADV_FREE), write and fork" operations on private anonymous mappings, creating the exact conditions where dirty page tracking information gets lost during write protection transitions. This flaw falls under CWE-1234 (Insecure Default Permissions) and relates to ATT&CK technique T1059.001 (Command and Scripting Interpreter: Shell Script) through indirect exploitation paths involving memory management corruption.
The resolution maintains the integrity of page dirty tracking throughout the kernel's memory management lifecycle by ensuring that software-aware dirty state information is preserved even when hardware PTW handles the initial dirty bit setting. This prevents data loss scenarios where modified pages might be freed without proper writeback during memory pressure events, and ensures that copy-on-write operations maintain accurate tracking of page modification status across process boundaries. The fix specifically addresses the architectural gap in LoongArch's memory management implementation while maintaining compatibility with existing kernel memory management functions and ensuring that pte_dirty() and pmd_dirty() functions correctly reflect the actual dirty state of pages regardless of whether the dirty information originated from hardware or software paths.