CVE-2026-53155

What it actually does

This Linux kernel memory-management flaw mishandles device-private transparent huge page PMD migration entries. The vulnerable code reads normal PMD flags such as writable, soft-dirty, and userfaultfd write-protect from a softleaf migration entry using the wrong helpers. On x86-64, soft-dirty state can be misinterpreted as write permission, causing read-only migrated mappings to be restored as writable. This can corrupt reverse-map accounting and create inconsistent AnonExclusive/mapcount state, potentially triggering kernel warnings, crashes, or memory-management corruption. Practical impact depends on kernel configuration and use of HMM/device-private memory features, such as GPU or accelerator memory migration support.

Why it matters to the business

Systems running affected Linux kernels with heterogeneous memory management or device-private memory features may be exposed to local reliability and integrity risk. In the most likely scenario, a local workload can trigger kernel warnings or denial of service through memory-management corruption. Because this issue is not in CISA KEV, has no known public exploit maturity, and has a very low EPSS score, broad internet-scale exploitation is unlikely; however, high-performance computing, GPU, AI/ML, virtualization, and accelerator-heavy environments should treat it as more relevant because they are more likely to use the affected code paths.

How an attack unfolds

An attacker would generally need local code execution on a system using a vulnerable kernel and device-private memory migration features. The attacker would allocate and fault in memory backed by transparent huge pages, cause migration to device-private memory, fork the process to create parent and child mappings, and then force a write/migration sequence that causes the kernel to interpret soft-dirty state as writability. The kernel may then install writable migration entries where read-only entries were intended, corrupt reverse-map state, and eventually hit kernel assertions or unstable memory-management behavior. There is no indication from the provided intelligence that this vulnerability is remotely exploitable, actively exploited, or used in ransomware campaigns.

How to fix it

Apply a Linux kernel update that includes the upstream fix for incorrect flag handling in set_pmd_migration_entry() for device-private PMD softleaf entries. If a vendor kernel is used, install the relevant distribution or appliance kernel security update once available. If immediate patching is not possible, reduce exposure by limiting untrusted local code execution on systems using HMM, ZONE_DEVICE, device-private memory, GPU/accelerator memory migration, or transparent huge pages. Where operationally feasible, disable or restrict device-private memory/HMM-related workloads until patched, especially on multi-user compute nodes.

How to confirm the fix worked

Confirm that the running kernel includes the fix for set_pmd_migration_entry() using the vendor advisory, package changelog, kernel source, or backport notes rather than relying only on the upstream version number. Validate that systems have rebooted into the updated kernel, not merely installed it. On source-based kernels, verify that set_pmd_migration_entry() references the correct softleaf entry fields for writable, soft-dirty, and userfaultfd write-protect state and only updates accessed/dirty flags for present entries. In test environments with appropriate hardware and configuration, run Linux HMM/device-private memory selftests, including huge-page migration scenarios, and confirm the kernel no longer emits reverse-map or AnonExclusive warnings.

Typical attack path

1. Obtain local ability to run code on a Linux system using a vulnerable kernel.
2. Exercise HMM/device-private memory functionality, typically through GPU or accelerator-backed memory migration paths.
3. Create transparent huge page mappings and migrate them to device-private memory.
4. Fork the process so parent and child share device-private PMD mappings with soft-dirty state.
5. Trigger writes and migration back to RAM so the kernel misreads soft-dirty bits as writable state.
6. Cause corrupted reverse-map and AnonExclusive accounting, potentially leading to kernel warnings, crashes, or memory-management instability.

How to detect it

There are no known public exploitation indicators from the provided intelligence, so detection should focus on signs that the vulnerable memory-management path was triggered. Review kernel logs, persistent journal entries, crash dumps, kdump/vmcore data, and system monitoring around unexplained reboots, kernel warnings, or crashes on systems using HMM/device-private memory, GPUs, accelerators, or transparent huge pages. Look for warnings involving AnonExclusive folios, folio_entire_mapcount, __folio_add_anon_rmap(), remove_migration_pmd(), set_pmd_migration_entry(), device-private migration, HMM tests, or transparent huge page migration. Correlate any such events with local user processes, GPU/accelerator workloads, container jobs, batch scheduler submissions, or test binaries exercising HMM/device-private memory. Absence of these artifacts does not prove non-exploitation because the issue may cause instability without leaving a clean application-level trace.

• VM_WARN_ON_FOLIO
• __folio_add_anon_rmap
• folio_entire_mapcount
• PageAnonExclusive
• AnonExclusive
• remove_migration_pmd
• set_pmd_migration_entry
• softleaf_is_migration_read
• pmdp_huge_get_and_clear
• device-private
• device private
• hmm_device_private
• anon_write_child
• test_hmm
• lib/test_hmm
• RMAP_EXCLUSIVE
• ZONE_DEVICE
• userfaultfd write-protect
• uffd-wp

What your security team should do

• Prioritize patching Linux systems that run GPU, accelerator, HMM, ZONE_DEVICE, AI/ML, HPC, or other device-private memory workloads.
• Inventory multi-user compute systems where untrusted users can run local code and verify whether they use affected kernel configurations or drivers.
• Track vendor kernel advisories and install the first fixed kernel available for each distribution or appliance image.
• After patch installation, reboot systems and verify the active running kernel is the fixed kernel.
• If patching is delayed, restrict untrusted local workloads on affected compute nodes and consider temporarily disabling affected accelerator memory migration features where feasible.
• Monitor kernel logs for reverse-map, AnonExclusive, migration PMD, and HMM selftest-related warnings or crashes.
• Treat exploitation likelihood as currently low because there is no KEV listing, no ransomware association, and no known exploit maturity, but do not ignore high-value shared compute platforms where local kernel denial of service is material.