CVE-2026-53189

What it actually does

This is a Linux kernel use-after-free vulnerability in the memory-management subsystem, specifically in huge page PMD splitting logic. During __split_huge_pmd_locked(), the kernel could release the last reference to a folio with folio_put() before updating the file or shared-memory RSS counter. If that release frees the folio, later counter logic can read stale folio state through folio_test_swapbacked(), resulting in a use-after-free read in kernel context. The most likely technical outcomes are kernel crash, memory corruption side effects, or denial of service; reliable privilege escalation has not been established from the available information.

Why it matters to the business

Successful exploitation could destabilize Linux systems and cause service outages, especially on workloads that heavily use transparent huge pages, shared memory, memory-mapped files, containers, databases, or high-memory applications. There is no indication that this vulnerability is in CISA KEV, used in ransomware campaigns, or has public exploit maturity at this time, and the EPSS score is very low, so urgency is primarily driven by exposure of critical Linux workloads and normal kernel patching cadence rather than active mass exploitation.

How an attack unfolds

An attacker would need a way to exercise the affected Linux memory-management path, typically by running local code or otherwise influencing workloads that create and split huge PMD mappings backed by file or shared memory. The attacker would attempt to trigger a race or state sequence in which __split_huge_pmd_locked() drops the last folio reference, freeing the folio, and then causes subsequent RSS counter handling to inspect the freed folio state. In practical terms, this is most plausibly exploited as a local denial-of-service condition resulting in a kernel oops, panic, or system instability. Turning this primitive into reliable code execution or privilege escalation would require additional exploit techniques and has not been demonstrated based on the provided data.

How to fix it

Apply a Linux kernel update that includes the fix moving the file/shmem RSS counter update before folio_put() in mm/huge_memory. Because no affected product list or fixed package versions were provided, use the fixed kernel version supplied by the relevant Linux distribution, cloud image provider, appliance vendor, or kernel maintainer. Prioritize patching internet-facing hosts, shared compute platforms, container hosts, virtualization nodes, database servers, and systems running memory-intensive workloads. If immediate patching is not possible, reduce risk by limiting untrusted local code execution, restricting shell access, isolating container tenants, and reviewing use of transparent huge pages or shmem-heavy workloads where operationally feasible; disabling transparent huge pages may reduce exposure to the affected code path but should be tested carefully for performance impact and should not be treated as a complete fix.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix for this vulnerability, not merely that an updated package is installed. Validate with the distribution security advisory, package changelog, kernel build metadata, or upstream commit reference associated with the mm/huge_memory folio_put() ordering fix. On Linux systems, compare the active kernel from uname -r with the patched kernel package version and reboot if the fixed kernel is installed but not running. Where source or debug symbols are available, verify that __split_huge_pmd_locked() updates the file/shmem RSS counter before dropping the folio reference. After remediation, monitor for recurrence of kernel oops or panic traces mentioning huge_memory, __split_huge_pmd_locked, folio_put, mm_counter_file, or folio_test_swapbacked.

Typical attack path

1. Obtain the ability to run code on a vulnerable Linux system or influence a workload that exercises file-backed or shared-memory huge page mappings.
2. Create memory pressure and mappings likely to use transparent huge pages, file-backed mappings, or shmem/tmpfs-backed mappings.
3. Trigger operations that split huge PMD mappings, such as memory advice changes, unmapping, remapping, page reclaim interactions, or workload-driven memory layout changes.
4. Attempt to hit the vulnerable ordering where folio_put() frees the folio before the file/shmem RSS counter reads folio state.
5. Observe or leverage the resulting kernel instability, crash, or potential memory-corruption side effects.

How to detect it

Because this vulnerability is in kernel memory-management logic and no public exploit pattern is provided, detection should focus on evidence that the vulnerable code path was triggered, especially unexplained kernel crashes or oops events. Review kernel logs, system journals, crash dumps, kdump/vmcore output, hypervisor reset events, and monitoring alerts for traces involving huge page splitting and folio state access. Useful sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, apport/ABRT crash records, kdump vmcore analysis, and SIEM-ingested kernel panic events. Look for call traces containing __split_huge_pmd_locked(), folio_put(), mm_counter_file(), folio_test_swapbacked(), split_huge_pmd, or mm/huge_memory. Correlate any matching crash with local user activity, container workloads, memory-intensive jobs, tmpfs/shmem usage, database activity, or sudden memory pressure. Absence of these logs does not prove non-exploitation, because a successful crash may truncate logs or only appear in crash dump infrastructure.

• __split_huge_pmd_locked
• folio_test_swapbacked
• mm_counter_file
• folio_put
• split_huge_pmd
• mm/huge_memory
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• kernel BUG at mm/huge_memory.c
• Oops:
• Kernel panic - not syncing
• Call Trace:
• /var/crash
• /var/lib/systemd/coredump
• /proc/vmcore

What your security team should do

• Track vendor advisories for all Linux distributions and kernel-derived products in use, and map each to the first fixed kernel package version.
• Patch and reboot critical Linux systems according to normal kernel security maintenance procedures, prioritizing multi-tenant, container-hosting, high-memory, and business-critical workloads.
• Treat this as a local kernel stability risk unless new exploit evidence emerges; there is currently no KEV listing, ransomware association, or known public exploit maturity from the provided data.
• Restrict untrusted local code execution and harden container boundaries on systems that cannot be patched promptly.
• Add monitoring for kernel oops, panic, and crash signatures involving huge_memory, __split_huge_pmd_locked, folio_put, mm_counter_file, and folio_test_swapbacked.
• Review crash dumps from the period since publication for matching memory-management traces to determine whether the bug may have been triggered.
• Ensure patch validation checks the running kernel after reboot, not only installed packages.