CVE-2026-53108: Linux Kernel Race Condition Vulnerability

CVE-2026-53108 Overview

CVE-2026-53108 is a race condition vulnerability in the Linux kernel affecting the PowerPC 64-bit server (powerpc/64s) memory management subsystem. The flaw occurs between PMD (Page Middle Directory) migration swap entries and concurrent munmap() operations on Transparent Huge Pages (THP). When move_pages() migrates a PMD THP page, it creates an intermediate state where the PMD entry acts as a migration swap entry. A concurrent munmap() call entering pmdp_huge_get_and_clear_full() triggers a VM_BUG_ON() assertion failure, causing a kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:187.

Critical Impact
A local unprivileged user can trigger a kernel BUG and denial of service by racing move_pages() against munmap() on PMD-sized THP pages on PowerPC 64-bit systems.

Affected Products

Linux kernel on PowerPC 64-bit server architecture (powerpc/64s)
Kernel builds with Transparent Huge Page (THP) support enabled
Kernel builds with device-private THP migration support (introduced by commit a30b48bf1b24)

Discovery Timeline

2026-06-24 - CVE-2026-53108 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-53108

Vulnerability Analysis

The vulnerability is a race condition [CWE-362] in the PowerPC book3s64 page table handling code. Two kernel threads can simultaneously manipulate a PMD entry that represents a huge page undergoing migration. Thread A executes a move_pages() syscall that calls set_pmd_migration_entry(), invalidating the PMD and installing a migration swap entry where pmd_present() returns false. Thread B concurrently executes munmap(), which traverses zap_pmd_range() and acquires the same page table lock after Thread A releases it during the page copy phase. Thread B then reaches pmdp_huge_get_and_clear_full(), where the VM_BUG_ON(!pmd_present(*pmdp)) assertion fires because the PMD now holds a swap entry rather than a present mapping.

The __pmd_trans_huge_lock() function treats the swap entry as a huge PMD because both pmd_present() and pmd_none() return false. This routes the unmap path into code that incorrectly assumes the PMD is present. A secondary warning at arch/powerpc/mm/book3s64/hash_pgtable.c:199 in hash__pmd_hugepage_update() triggers via the same race when device-private THP migration is used.

Root Cause

The root cause is missing handling for non-present PMD migration swap entries in the PowerPC 64-bit huge page unmap path. The architecture-specific pmdp_huge_get_and_clear_full() implementation asserts the PMD must be present, but the generic mm layer can legitimately reach this code with a migration swap entry installed by another CPU.

Attack Vector

A local unprivileged process can reliably trigger the race by issuing move_pages() and munmap() concurrently against a PMD-sized THP-backed mapping. The crash occurs in process context and panics the kernel thread, producing the call trace through sys_munmap → __vm_munmap → unmap_vmas → zap_huge_pmd → pmdp_huge_get_and_clear_full. Successful exploitation results in denial of service on the affected PowerPC system. No memory corruption primitive is documented in the upstream report. See the upstream commits 829367e55012 and bbcbf045d6c7 for the technical fix.

Detection Methods for CVE-2026-53108

Indicators of Compromise

Kernel log entries containing kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:187
Stack traces showing pmdp_huge_get_and_clear_full+0x6c/0x23c called from zap_huge_pmd
Warnings at arch/powerpc/mm/book3s64/hash_pgtable.c:199 in hash__pmd_hugepage_update
Unexpected process termination on PowerPC hosts during workloads using move_pages() and munmap() on THP regions

Detection Strategies

Monitor /var/log/kern.log and dmesg output for the specific BUG and WARNING signatures referenced above on PowerPC 64-bit systems
Correlate kernel panics with processes invoking NUMA page migration syscalls against THP-backed memory
Audit kernel versions on PowerPC fleet to identify hosts running unpatched 6.x kernels with THP and device-private migration enabled

Monitoring Recommendations

Enable persistent kernel crash collection (kdump) on PowerPC hosts to capture vmcores when the BUG fires
Forward kernel logs to a centralized log analytics platform and alert on kernel BUG strings originating from book3s64 paths
Track move_pages syscall frequency on workloads that also perform aggressive munmap() to identify exposure

How to Mitigate CVE-2026-53108

Immediate Actions Required

Apply the upstream fixes from commits 829367e55012 and bbcbf045d6c7 on all PowerPC 64-bit systems
Track distribution backports for RHEL, SLES, Ubuntu, and Debian PowerPC kernel packages and schedule rolling reboots
Prioritize patching on multi-tenant PowerPC hosts where untrusted users can execute the move_pages syscall

Patch Information

The fix resolves the race by handling non-present PMD migration swap entries in the PowerPC unmap path so that pmdp_huge_get_and_clear_full() no longer triggers VM_BUG_ON when a concurrent migration is in progress. Refer to the Kernel Git Commit Details for the patch content and the companion commit for the hash MMU fix.

Workarounds

Disable Transparent Huge Pages on affected PowerPC hosts by setting transparent_hugepage=never on the kernel command line until patches are applied
Restrict use of NUMA migration syscalls (move_pages, migrate_pages) via seccomp filters for untrusted workloads
Avoid loading the test_hmm module and disable device-private THP migration features on production PowerPC systems where feasible

bash

# Configuration example: disable THP at boot on PowerPC hosts
# Edit /etc/default/grub and append to GRUB_CMDLINE_LINUX:
GRUB_CMDLINE_LINUX="... transparent_hugepage=never"

# Rebuild GRUB config and reboot
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo reboot

# Verify THP is disabled after reboot
cat /sys/kernel/mm/transparent_hugepage/enabled
# Expected output: always madvise [never]