CVE-2026-72043: LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()

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 PAGEDIRTY 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 PAGEDIRTY andPAGEMODIFIED together:

ori t0, t0, (PAGEVALID | PAGEDIRTY | PAGEMODIFIED)

Since hardware PTW only sets PAGEDIRTY, the software-only bit, i.e. PAGEMODIFIED is left unchanged. This creates a window where a PTE has PAGEDIRTY set (hardware knows the page is dirty) but PAGEMODIFIED clear (software is unaware).

When fork()/clone() triggers copy-on-write, copypresentptes() calls ptewrprotect(), which unconditionally clears both the PAGEWRITE and PAGEDIRTY bits:

pteval(pte) &= ~(PAGEWRITE | PAGEDIRTY);

Since PAGEMODIFIED was never set, the dirtiness information is lost completely. Subsequently, when memory pressure triggers page reclaim, pagemkclean() / trytounmap() sees the page as clean (i.e. ptedirty() returns false) and the page may be freed without writeback, causing data corruption.

Fix this by propagating the PAGEDIRTY bit to the PAGEMODIFIED bit in both ptewrprotect() and pmdwrprotect() before clearing writeable bits:

if (pteval(pte) & PAGEDIRTY) pteval(pte) |= PAGEMODIFIED;

The pmdwrprotect() fix handles the CONFIGTRANSPARENTHUGEPAGE case, where pmd entries need the same treatment.

This ensures the software dirty tracking bit (checked by ptedirty() and pmddirty(), which read both the PAGEDIRTY and PAGEMODIFIED bits) is preserved across fork COW write-protection.

The issue was found by the LTP madvise09 test case, which exercises page reclaim after "madvise(MADVFREE), write and fork" operation sequence on private anonymous mappings.