CVE-2026-53109: powerpc/pgtable-frag: Fix bad page state in pte_frag_destroy

In the Linux kernel, the following vulnerability has been resolved:

powerpc/pgtable-frag: Fix bad page state in ptefragdestroy

powerpc uses ptfragrefcount as a reference counter for tracking it's pte and pmd page table fragments. For PTE table, in case of Hash with 64K pagesize, we have 16 fragments of 4K size in one 64K page.

Patch series [1] "mm: free retracted page table by RCU" added ptefreedefer() to defer the freeing of PTE tables when retractpagetables() is called for madvise MADVCOLLAPSE on shmem range. [1]: https://lore.kernel.org/all/7cd843a9-aa80-14f-5eb2-33427363c20@google.com/

ptefreedefer() sets the active flag on the corresponding fragment's folio & calls ptefragmentfree(), which reduces the ptfragrefcount. When ptfragrefcount reaches 0 (no active fragment using the folio), it checks if the folio active flag is set, if set, it calls callrcu to free the folio, it the active flag is unset then it calls ptefreenow().

Now, this can lead to following problem in a corner case...

[ 265.351553][ T183] BUG: Bad page state in process a.out pfn:20d62 [ 265.353555][ T183] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x20d62 [ 265.355457][ T183] flags: 0x3ffff800000100(active|node=0|zone=0|lastcpupid=0x7ffff) [ 265.358719][ T183] raw: 003ffff800000100 0000000000000000 5deadbeef0000122 0000000000000000 [ 265.360177][ T183] raw: 0000000000000000 c0000000119caf58 00000000ffffffff 0000000000000000 [ 265.361438][ T183] page dumped because: PAGEFLAGSCHECKATFREE flag(s) set [ 265.362572][ T183] Modules linked in: [ 265.364622][ T183] CPU: 0 UID: 0 PID: 183 Comm: a.out Not tainted 6.18.0-rc3-00141-g1ddeaaace7ff-dirty #53 VOLUNTARY [ 265.364785][ T183] Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) 0x801200 0xf000006 of:SLOF,git-ee03ae pSeries [ 265.364908][ T183] Call Trace: [ 265.364955][ T183] [c000000011e6f7c0] [c000000001cfaa18] dumpstacklvl+0x130/0x148 (unreliable) [ 265.365202][ T183] [c000000011e6f7f0] [c000000000794758] badpage+0xb4/0x1c8 [ 265.365384][ T183] [c000000011e6f890] [c00000000079c020] freefrozenpages+0x838/0xd08 [ 265.365554][ T183] [c000000011e6f980] [c0000000000a70ac] ptefragdestroy+0x298/0x310 [ 265.365729][ T183] [c000000011e6fa30] [c0000000000aa764] archexitmmap+0x34/0x218 [ 265.365912][ T183] [c000000011e6fa80] [c000000000751698] exitmmap+0xb8/0x820 [ 265.366080][ T183] [c000000011e6fc30] [c0000000001b1258] mmput+0x98/0x300 [ 265.366244][ T183] [c000000011e6fc80] [c0000000001c81f8] doexit+0x470/0x1508 [ 265.366421][ T183] [c000000011e6fd70] [c0000000001c95e4] dogroupexit+0x88/0x148 [ 265.366602][ T183] [c000000011e6fdc0] [c0000000001c96ec] pidchildshouldwake+0x0/0x178 [ 265.366780][ T183] [c000000011e6fdf0] [c00000000003a270] systemcallexception+0x1b0/0x4e0 [ 265.366958][ T183] [c000000011e6fe50] [c00000000000d05c] systemcallvectoredcommon+0x15c/0x2ec

The bad page state error occurs when such a folio gets freed (with active flag set), from doexit() path in parallel.

... this can happen when the pte fragment was allocated from this folio, but when all the fragments get freed, the ptefragrefcount still had some unused fragments. Now, if this process exits, with such folio as it's cached ptefrag in mm->context, then during ptefragdestroy(), we simply call pagetabledtor() and pagetablefree(), meaning it doesn't clear the active flag. This, can lead to the above bug. Since we are anyway in doexit() path, then if the refcount is 0, then I guess it should be ok to simply clear the folio active flag before calling pagetabledtor() & pagetablefree().