CVE-2026-53189: Linux Kernel Use-After-Free Vulnerability

CVE-2026-53189 Overview

CVE-2026-53189 is a use-after-free vulnerability in the Linux kernel's transparent huge page (THP) memory management subsystem. The flaw resides in __split_huge_pmd_locked() within mm/huge_memory.c. The function updates the file/shmem Resident Set Size (RSS) counter after dropping the Page Middle Directory (PMD) mapping's folio reference. If folio_put() releases the last reference, the folio memory can be freed before mm_counter_file() reads its state via folio_test_swapbacked(). This creates a window where freed folio state is accessed. The fix moves the counter update before folio_put() to eliminate the race.

Critical Impact
Local processes triggering PMD splits on file or shmem-backed transparent huge pages can cause reads of freed kernel memory, potentially leading to kernel information disclosure, instability, or memory corruption.

Affected Products

Linux kernel versions containing the vulnerable __split_huge_pmd_locked() implementation in mm/huge_memory.c
Distributions shipping affected upstream kernel trees prior to the referenced stable commits
Systems with transparent huge page support enabled for file-backed or shmem mappings

Discovery Timeline

2026-06-25 - CVE-2026-53189 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-53189

Vulnerability Analysis

The defect is a use-after-free condition in the Linux kernel's huge page splitting code path. When __split_huge_pmd_locked() processes a file-backed or shmem-backed PMD mapping, it must release the folio reference and update the RSS counter for accounting. The original ordering called folio_put() first, then invoked mm_counter_file(folio), which internally calls folio_test_swapbacked(folio) to determine whether to charge MM_SHMEMPAGES or MM_FILEPAGES.

If the folio_put() call drops the final reference, the folio is freed and returned to the allocator. The subsequent folio_test_swapbacked() call then reads flags from a freed struct folio, yielding stale or attacker-influenced data. The fix reorders the operations so that mm_counter_file() runs while the folio reference is still held.

Root Cause

The root cause is incorrect operation ordering in __split_huge_pmd_locked(). The counter update reads folio state through folio_test_swapbacked() after the reference count may have reached zero. This violates the lifetime rule that folio state must only be accessed while a reference is held. The result is a classic use-after-free [CWE-416] on kernel memory metadata.

Attack Vector

Triggering the bug requires a workload that causes the kernel to split a file or shmem PMD mapping while concurrently dropping references to the underlying folio. Conditions that lead to PMD splits include partial unmaps (munmap()), madvise() calls such as MADV_DONTNEED, memory pressure-driven reclaim, and migration. An unprivileged local process operating on tmpfs or other file-backed huge page mappings can reach the vulnerable path. The vulnerability is not network-reachable; exploitation requires local code execution and the ability to manipulate huge page mappings. See the kernel stable tree commits for the corrected ordering.

Detection Methods for CVE-2026-53189

Indicators of Compromise

Unexplained kernel oops, BUG, or KASAN reports referencing __split_huge_pmd_locked, folio_test_swapbacked, or mm_counter_file
Inconsistent RSS accounting values in /proc/<pid>/status for processes using tmpfs or file-backed THP
Kernel panics or memory corruption traces during heavy madvise() or munmap() activity on huge-page-backed regions

Detection Strategies

Enable Kernel Address Sanitizer (KASAN) in test environments to surface use-after-free reads against folio structures
Audit running kernel versions against the fixed commit hashes (108963978a68, 459771c9cf30, 5f5b604e1e6b, 6c29a8ba084e, 84b3212b166b, 8d878059924f, ae9d4caf6f13, ed5b03093129) using uname -r and distribution package metadata
Collect kernel ring buffer output (dmesg) for anomalies in the memory management subsystem on hosts with transparent huge pages enabled

Monitoring Recommendations

Forward kernel logs to a centralized SIEM and alert on stack traces involving huge_memory.c or folio reference functions
Track kernel package versions across the fleet and flag hosts running unpatched builds
Monitor process termination events tied to segmentation faults that correlate with THP-heavy workloads

How to Mitigate CVE-2026-53189

Immediate Actions Required

Apply the stable kernel updates containing the reordered counter update in __split_huge_pmd_locked() from your distribution vendor
Inventory all Linux hosts and identify kernels predating the fix commits referenced in the kernel.org advisory
Prioritize patching on multi-tenant systems, containers hosts, and shared infrastructure where untrusted local code may execute

Patch Information

The upstream fix moves mm_counter_file() before folio_put() in __split_huge_pmd_locked(). The patch is available across multiple stable branches via the following commits: 108963978a68, 459771c9cf30, 5f5b604e1e6b, 6c29a8ba084e, 84b3212b166b, 8d878059924f, ae9d4caf6f13, and ed5b03093129. Rebuild or install vendor kernels that include these changes, then reboot affected systems.

Workarounds

Where patching is delayed, consider disabling transparent huge pages for file-backed mappings by setting /sys/kernel/mm/transparent_hugepage/shmem_enabled to never
Restrict local access on multi-tenant systems and limit which users can mount tmpfs or create large file-backed mappings
Apply distribution-provided live patches if available for the relevant kernel branch

bash

# Verify kernel version and disable shmem THP as a temporary workaround
uname -r
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/shmem_enabled
cat /sys/kernel/mm/transparent_hugepage/shmem_enabled