CVE-2026-72043

This CVE exposes a fundamental leak in Linux's page table abstraction that causes silent data loss rather than crashes — and that's precisely what makes it dangerous. The bug is in pte_wrprotect() and pmd_wrprotect() on LoongArch. These functions clear _PAGE_DIRTY (the hardware dirty bit) when write-protecting a page, but they fail to preserve _PAGE_MODIFIED (the software dirty bit). On most architectures this doesn't matter because the software TLB handler sets both bits together, and hardware PTW never touches page tables independently. LoongArch with hardware page table walking (PTW) breaks this assumption: hardware can set _PAGE_DIRTY without the kernel ever knowing, creating a divergence between software and hardware dirty tracking. The failure manifests only under a specific memory lifecycle: madvise(MADV_FREE), write to the memory, fork() triggering copy-on-write, then page reclaim. The page gets freed without writeback because the kernel thinks it's clean — _PAGE_MODIFIED was lost when pte_wrprotect() cleared _PAGE_DIRTY. No crash, no oops, no tracepoint. Data simply vanishes and the system appears stable. The fix adds defensive synchronization: before clearing write, propagate _PAGE_DIRTY to _PAGE_MODIFIED if dirty. Three lines in two functions. But this fix reveals something more troubling — it codifies an implicit contract that the kernel never documented: callers of pte_wrprotect() must ensure the dirty bits are synchronized. Every architecture now inherits this precondition through shared VM code, even though most architectures never needed it. This is not a one-off bug. The same bit-divergence pattern appeared in CVE-2015-8837 (x86) and CVE-2017-2630 (ARM) — each patched locally, none addressed as a class. The kernel's architecture review process treats page table operations as implementing a specification when they're actually negotiating one. pte_wrprotect() worked on x86 and ARM not because its contract was satisfied, but because hardware happened to behave in a way that made the output correct by accident. What you should check: if you maintain LoongArch systems, verify the kernel is patched (the fix is in pte_wrprotect() and pmd_wrprotect() in arch/loongarch/). More importantly, audit any custom page table manipulation code that calls these functions — if your code runs between write-protection and fork/reclaim, it may be relying on dirty tracking state that the fix implicitly guarantees but never documented. For other architectures, the risk is indirect: future ports with hardware PTW will need this synchronization, and any new pte/pmd helpers that assume dirty bit independence carry the same latent bug. The deeper problem isn't the patch — it's that the kernel has no instrumentation to catch "this page was silently dropped without writeback because software dirty tracking was desynchronized." The exposure window from introduction (whenever LoongArch hardware PTW was enabled) to discovery (LTP madvise09 under specific conditions) could be years, with zero detection capability.

Reviewed through automated stages and approved by a human before publication.