CVE-2026-53108

What it actually does

This is a Linux kernel race condition in the PowerPC 64-bit Book3S memory-management code involving PMD-level transparent huge page migration entries. During page migration, such as via move_pages() or device-private transparent huge page migration, a PMD can temporarily represent a migration swap entry while another thread concurrently unmaps the same memory range through munmap(). On affected kernels, the unmap path can treat the transient PMD state as a huge PMD and then hit a VM_BUG_ON() assertion in pmdp_huge_get_and_clear_full(), resulting in a kernel BUG, warning, or crash. The practical technical impact is local denial of service through kernel panic or system instability on affected PowerPC systems; there is no indication from the provided information of remote exploitation, privilege escalation, or data disclosure.

Why it matters to the business

Organizations running affected Linux kernels on PowerPC 64-bit systems may experience unexpected host crashes or workload disruption if the race is triggered by local processes using memory migration, huge pages, or device-private memory paths. This can affect availability of applications, batch workloads, virtualization, high-performance computing, or systems using heterogeneous memory/device migration features. The current exploitation likelihood appears low based on the very low EPSS score, lack of known exploitation, lack of KEV listing, and no reported ransomware use, but kernel availability issues can still be operationally significant for critical PowerPC workloads.

How an attack unfolds

An attacker or unprivileged local user would need the ability to run code on an affected PowerPC 64-bit Linux system and exercise memory-management paths that create PMD migration entries, such as page migration involving transparent huge pages or device-private huge page migration. One execution thread causes a PMD-backed huge page to enter a temporary migration-entry state, while another concurrently unmaps the same memory region. If the timing lands in the vulnerable race window, the kernel unmap path may mis-handle the transient PMD state and trigger a kernel BUG or warning in the PowerPC page-table code. A successful exploit would most likely crash the kernel or destabilize the host, causing denial of service rather than giving the attacker additional privileges.

How to fix it

Apply a Linux kernel update that includes the PowerPC 64s fix for the PMD migration-entry unmap race. Because no exact fixed package versions were provided, use the fixed kernel versions from the relevant Linux distribution, hardware vendor, or kernel branch advisory and prioritize PowerPC 64-bit systems. Where immediate patching is not possible, reduce exposure by limiting local shell access, container breakout opportunities, and untrusted code execution on affected PowerPC hosts; consider disabling or avoiding workloads that rely on transparent huge page migration, device-private memory migration, HMM test paths, or aggressive page migration where operationally feasible. Mitigations should be treated as temporary because the defect is in kernel memory-management logic and is best addressed by installing the corrected kernel and rebooting into it.

How to confirm the fix worked

Confirm exposure by identifying PowerPC 64-bit systems running Linux kernels that predate the vendor fix for this issue, especially kernels with transparent huge page and device-private page migration support. Validate remediation by confirming the running kernel version after reboot matches a vendor-fixed build and by checking distribution changelogs or kernel commit history for the PowerPC 64s PMD migration-entry unmap race fix. Operational validation should include monitoring that prior kernel BUG or warning signatures no longer appear under representative memory migration, huge page, and unmap workloads. Do not rely solely on package installation state; verify the active booted kernel with system inventory or host commands such as uname -a.

Typical attack path

1. Gain the ability to execute local code on an affected PowerPC 64-bit Linux host.
2. Allocate or interact with memory regions backed by transparent huge pages or device-private huge page mappings.
3. Trigger page migration behavior, for example through memory migration mechanisms such as move_pages() or device-private migration paths.
4. Concurrently unmap the affected memory region with munmap() while the PMD is in a transient migration-entry state.
5. Win the race so the unmap path handles the migration entry as a huge PMD and reaches the vulnerable assertion path.
6. Cause a kernel BUG, warning, panic, or system instability, resulting in local denial of service.

How to detect it

Look for evidence of prior kernel BUGs, warnings, panics, or crashes in kernel logs and crash dumps on PowerPC 64-bit Linux systems. Relevant log sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, netconsole output, hypervisor console captures, kdump/vmcore records, and hardware management console logs. Search for stack traces involving pmdp_huge_get_and_clear_full(), zap_huge_pmd(), pmd_is_huge(), set_pmd_migration_entry(), hash__pmd_hugepage_update(), hash__pmdp_huge_get_and_clear(), migrate_vma, move_pages, munmap, transparent huge page migration, or hmm-tests/test_hmm. Exploitation may not leave a clean user-space indicator because the expected outcome is a kernel crash; correlate any matching kernel trace with preceding local process execution, memory migration activity, HMM/device-private memory tests, container jobs, or unusual repeated host crashes. Named threat-actor exploitation has not been provided, so detection should focus on crash forensics and repeated attempts to trigger the vulnerable memory-management race rather than actor-specific infrastructure.

• kernel BUG at arch/powerpc/mm/book3s64/pgtable.c
• pmdp_huge_get_and_clear_full
• zap_huge_pmd
• VM_BUG_ON(!pmd_present(*pmdp))
• Program Check
• system_call_exception
• sys_munmap
• set_pmd_migration_entry
• hash__pmd_hugepage_update
• hash__pmdp_huge_get_and_clear
• arch/powerpc/mm/book3s64/hash_pgtable.c
• migrate_vma
• move_pages
• hmm-tests
• test_hmm
• PMD: migration swap entry
• WARNING: arch/powerpc/mm/book3s64/hash_pgtable.c
• kernel BUG at :187
• powerpc64le-linux-gnu
• Hardware name: IBM pSeries
• POWER10

What your security team should do

• Inventory PowerPC 64-bit Linux systems and determine which are running kernels without the vendor fix.
• Prioritize patching and rebooting systems that run untrusted local code, multi-user workloads, containers, HPC jobs, device-private memory workloads, HMM-related workloads, or transparent huge page migration-heavy applications.
• Review kernel logs for prior crash, BUG, warning, or panic signatures matching the affected PowerPC memory-management paths.
• Restrict local code execution and reduce untrusted workload placement on exposed PowerPC hosts until patched.
• Coordinate maintenance windows for kernel upgrades because remediation requires booting into a fixed kernel.
• Track vendor advisories for exact fixed package versions for each deployed distribution or appliance using Linux on PowerPC.
• Because this is not listed in KEV, has no known ransomware association, and has very low EPSS, prioritize based on asset criticality and exposure to untrusted local users rather than emergency internet-facing risk.