CVE-2026-53109

NONECVSS 0.0
0.0
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • No confirmed exploitation signals yet
CISA-KEV: Not listedEPSS: 0%CVSS: Exploit: NoneExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

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

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

powerpc uses pt_frag_refcount 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 pte_free_defer() to defer the freeing of PTE tables when retract_page_tables() is called for madvise MADV_COLLAPSE on shmem range. [1]: https://lore.kernel.org/all/[email protected]/

pte_free_defer() sets the active flag on the corresponding fragment's folio & calls pte_fragment_free(), which reduces the pt_frag_refcount. When pt_frag_refcount reaches 0 (no active fragment using the folio), it checks if the folio active flag is set, if set, it calls call_rcu to free the folio, it the active flag is unset then it calls pte_free_now().

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: PAGE_FLAGS_CHECK_AT_FREE 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] dump_stack_lvl+0x130/0x148 (unreliable) [ 265.365202][ T183] [c000000011e6f7f0] [c000000000794758] bad_page+0xb4/0x1c8 [ 265.365384][ T183] [c000000011e6f890] [c00000000079c020] __free_frozen_pages+0x838/0xd08 [ 265.365554][ T183] [c000000011e6f980] [c0000000000a70ac] pte_frag_destroy+0x298/0x310 [ 265.365729][ T183] [c000000011e6fa30] [c0000000000aa764] arch_exit_mmap+0x34/0x218 [ 265.365912][ T183] [c000000011e6fa80] [c000000000751698] exit_mmap+0xb8/0x820 [ 265.366080][ T183] [c000000011e6fc30] [c0000000001b1258] __mmput+0x98/0x300 [ 265.366244][ T183] [c000000011e6fc80] [c0000000001c81f8] do_exit+0x470/0x1508 [ 265.366421][ T183] [c000000011e6fd70] [c0000000001c95e4] do_group_exit+0x88/0x148 [ 265.366602][ T183] [c000000011e6fdc0] [c0000000001c96ec] pid_child_should_wake+0x0/0x178 [ 265.366780][ T183] [c000000011e6fdf0] [c00000000003a270] system_call_exception+0x1b0/0x4e0 [ 265.366958][ T183] [c000000011e6fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec

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

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

CVSS v3
EG Score
0.0(none)
EPSS
5.7%
KEV
Not listed

Published

June 24, 2026

Last Modified

June 24, 2026

Vendor Advisories for CVE-2026-53109(2)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Data Freshness Timeline

(refreshed 11× in last 7d / 22× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-07-06 16:27 UTCEPSS rescore
  2. 2026-07-06 16:27 UTCEPSS rescore
  3. 2026-07-06 02:23 UTCEPSS rescore
  4. 2026-07-06 02:23 UTCEPSS rescore
  5. 2026-07-05 02:31 UTCEPSS rescore
  6. 2026-07-05 02:30 UTCEPSS rescore
  7. 2026-07-04 10:24 UTCGHSA enrichment
  8. 2026-07-04 06:31 UTCEPSS rescore
  9. 2026-07-01 15:07 UTCEPSS rescore
  10. 2026-07-01 04:59 UTCGHSA enrichment
  11. 2026-06-30 23:22 UTCEPSS rescore
  12. 2026-06-29 14:06 UTCEPSS rescore
  13. 2026-06-29 14:06 UTCEPSS rescore
  14. 2026-06-28 14:07 UTCEPSS rescore
  15. 2026-06-28 04:56 UTCEPSS rescore
  16. 2026-06-28 04:56 UTCEPSS rescore
  17. 2026-06-27 23:34 UTCEG score recompute
  18. 2026-06-27 23:34 UTCGHSA enrichment
  19. 2026-06-27 03:08 UTCEPSS rescore
  20. 2026-06-25 13:49 UTCEPSS rescore
  21. 2026-06-24 18:10 UTCEG score recompute
  22. 2026-06-24 18:03 UTCNVD updatefirst tracked

Frequently asked(4)

What is CVE-2026-53109?
CVE-2026-53109 is a none vulnerability published on June 24, 2026. 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…
When was CVE-2026-53109 disclosed?
CVE-2026-53109 was first published in the National Vulnerability Database on June 24, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-53109 actively exploited?
CVE-2026-53109 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 5.7% percentile likelihood of exploitation in the next 30 days — higher percentiles indicate greater predicted risk.
How do I remediate CVE-2026-53109?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-53109, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-53109

Explore →

Is Your Infrastructure Affected by CVE-2026-53109?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.