HIGH 7.8

CVE-2026-53109: PowerPC Linux Kernel Page Table Fragment Memory Corruption

CVE-2026-53109 is a memory management bug in the Linux kernel's PowerPC architecture code that can cause a system crash or data corruption when page table fragments are freed. The vulnerability occurs in a specific scenario involving deferred page table cleanup (introduced in a recent kernel patch series) combined with process exit. When certain conditions align—particularly when cached page table fragments retain references but are freed during program termination—the kernel incorrectly manages the active flag on memory pages, leading to a kernel panic with "Bad page state" errors. This is a local vulnerability requiring user-level code execution on an affected system.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.8 HIGH · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weaknesses (CWE)
CWE-416
Affected products
1 configuration(s)
Published / Modified
2026-06-24 / 2026-07-23

NVD description (verbatim)

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().

3 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The vulnerability exists in PowerPC's page table fragment management, specifically in the interaction between pte_free_defer() (which defers PTE table freeing via RCU) and pte_frag_destroy() (invoked during process exit). On PowerPC systems using Hash MMU with 64K page size, page tables are divided into 16 fragments of 4K each. The pte_free_defer() function sets the active flag on fragment folios and decrements pt_frag_refcount. When refcount reaches zero, the code should conditionally call RCU-deferred freeing or immediate freeing based on the active flag state. However, when pte_frag_destroy() is called from the do_exit() path on a process with cached fragments, it unconditionally calls pagetable_dtor() and pagetable_free() without clearing the active flag first. This leaves the folio with the active flag set while being freed, violating kernel page state invariants and triggering the kernel's bad page detection mechanism. The root cause is a missing flag clear operation before final deallocation in the exit path.

Business impact

Organizations running PowerPC-based Linux systems in production environments (such as IBM Power Systems) face potential service interruptions. Affected workloads may experience sudden kernel panics during process termination, causing data loss, interrupted batch jobs, and unplanned downtime. The impact is most significant for deployments using memory-intensive applications or those with frequent process churn. However, the vulnerability is limited to PowerPC architecture and requires specific page table configurations (Hash MMU with 64K pages), limiting scope compared to x86-dominant infrastructures. Enterprise support contracts with Linux vendors will be critical for rapid patch deployment.

Affected systems

Linux kernels on PowerPC architecture are affected, specifically versions that include the deferred page table freeing patch series. Affected configurations require Hash MMU (not Radix) and 64K page size. Systems at risk include IBM Power9 and Power10 servers running distributions with recent kernel updates. The vulnerability does not affect x86, ARM, or other non-PowerPC architectures. Verify your kernel version and PowerPC MMU configuration against vendor advisories to determine exposure.

Exploitability

Exploitation requires local code execution on the target system with user-level privileges. An attacker cannot trigger this remotely or from an unprivileged context. The attack vector is straightforward: running a crafted user-space program designed to allocate page table fragments and then exit under conditions that trigger the bad state condition. No special kernel capabilities or elevated privileges are needed to trigger the crash itself, though the impact (denial of service via kernel panic) affects the entire system. The low complexity and lack of interaction requirements make this practical for local attackers.

Remediation

Apply kernel patches that restore proper active flag management in pte_frag_destroy(). The fix involves adding a clear_bit() operation to unset the active flag on the folio before calling pagetable_dtor() and pagetable_free() in the exit path. Consult your Linux vendor or distribution's security advisories for patch availability and version numbers. Organizations should prioritize kernel updates on PowerPC systems, especially those running madvise MADV_COLLAPSE workloads or memory-intensive applications. Testing patches in staging environments before production rollout is recommended to catch any interactions with custom kernels or out-of-tree modules.

Patch guidance

Kernel maintainers should prioritize patch development for affected kernel branches. The fix is targeted to the PowerPC pgtable-frag code path and should have minimal risk of regressions. Distributors should backport patches to stable/LTS kernel branches and release updates through their normal security channels. For users: monitor your vendor's security advisories (Red Hat, SUSE, IBM, Canonical) for kernel updates addressing this CVE. Apply patches during scheduled maintenance windows. Verify patch application by checking kernel version and running system validation tests to confirm page table behavior.

Detection guidance

Monitor system logs for "BUG: Bad page state" messages combined with stack traces mentioning pte_frag_destroy() or arch_exit_mmap(). Systems vulnerable to this issue will show characteristic kernel panic logs with PAGE_FLAGS_CHECK_AT_FREE flag errors. Check kernel version against patched releases provided by your vendor. Organizations using kernel introspection tools can inspect pt_frag_refcount values and folio active flags during normal operation to establish baselines; deviations may indicate vulnerability exploitation or environmental issues. Enable kernel debugging (CONFIG_DEBUG_PAGEALLOC) on non-production systems to catch related issues early.

Why prioritize this

Despite a CVSS 7.8 rating, this vulnerability should be prioritized based on deployment footprint rather than raw score. PowerPC systems represent a smaller attack surface than x86 environments, but they are often critical infrastructure (financial services, enterprise HPC, government). The combination of local attack surface and system-wide crash impact makes this HIGH priority for affected organizations. Prioritize based on: (1) presence of PowerPC infrastructure, (2) reliance on high-uptime SLAs, (3) deployment of recent kernels with MADV_COLLAPSE support. Organizations without PowerPC systems can defer action but should monitor for backported fixes in x86-targeted CVEs that may have related root causes.

Risk score, explained

The CVSS 3.1 score of 7.8 (HIGH severity) reflects high impact (crash/DoS affecting confidentiality, integrity, availability) combined with low attack complexity and low privileges required. The score appropriately penalizes the local-only attack vector. However, the score does not account for limited affected population (PowerPC only), which in real-world risk assessment would lower practical severity for x86-dominant enterprises. The lack of KEV status and active exploitation signals currently indicates this is pre-mitigation intelligence; threat actors may target PowerPC systems once patches are public and exploitation methods are documented.

Frequently asked questions

Is this vulnerability exploitable remotely or only locally?

Only locally. An attacker needs code execution on the affected PowerPC system. Remote exploitation is not possible. However, if an attacker already has local access (via SSH, application compromise, etc.), they can reliably trigger a kernel panic.

Which Linux distributions are affected?

Any distribution running Linux kernels on PowerPC architecture with Hash MMU (not Radix) and 64K page size configuration. This includes Red Hat Enterprise Linux on Power, SUSE Linux Enterprise Server on Power, and Ubuntu on Power. Check your vendor's security advisory for specific affected versions. x86 and ARM systems are not affected.

What happens when the vulnerability is exploited?

The kernel enters a panic state with a "Bad page state" error, causing an unplanned system reboot. This denies service to all running applications on that system. Data loss may occur for in-flight transactions if not properly journaled. The kernel does not maintain stability after this error occurs.

Can I disable a feature to avoid this vulnerability until I patch?

Not practically. The vulnerability is triggered during normal process exit when certain page table memory layouts are present. There is no configuration flag to disable page table management. The safest mitigation is kernel patching; workarounds are limited to reducing workload intensity or deferring long-running processes until patched kernels are deployed.

This analysis is provided for informational purposes and represents SEC.co's assessment based on available vulnerability data as of the publication date. Organizations should verify CVE details, affected product versions, and patch availability against official vendor advisories and their specific system configurations before making remediation decisions. No exploit code or weaponized proof-of-concept is provided. This vulnerability's impact is limited to PowerPC architecture systems; organizations running exclusively x86 or ARM infrastructure are not affected. Patch testing in non-production environments is strongly recommended before enterprise deployment. Source: NVD (public-domain), retrieved 2026-08-02. Analysis generated by SEC.co (claude-haiku-4-5).