CVE-2026-31466

What it actually does

This is a Linux kernel memory-management race condition in the handling of migration entries during multi-size transparent huge page splitting. A missing read memory barrier in softleaf_to_folio() and softleaf_to_page() can allow one CPU to observe a tail page as no longer compound before its page flags, including the locked state, are visible. Under a narrow race between folio splitting and page-table zapping, the kernel can operate on a folio as though it is properly locked when the lock state has not been observed, triggering VM_WARN_ON_ONCE() or, on some kernel versions/configurations, a BUG/panic path. The practical impact is local denial of service through kernel warning escalation or crash; the CVSS vector indicates local access, low privileges, no user interaction, high attack complexity, and high availability impact with no direct confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can crash or destabilize Linux systems, causing service interruption, workload restarts, node evacuation, or downtime for applications hosted on affected kernels. The risk is most relevant to multi-user systems, container hosts, virtualization platforms, CI/build servers, and other environments where untrusted or semi-trusted local users can run code. There is currently no known public exploit maturity, the EPSS probability is very low and flat over the last 30 days, and the issue is not listed in CISA KEV or associated with ransomware campaigns, so urgency is primarily driven by exposure of local shell/container workloads and the operational importance of kernel availability.

How an attack unfolds

An attacker first needs the ability to execute code locally on an affected Linux system, such as through a shell account, compromised service account, container escape-adjacent workload context, or other low-privileged execution path. The attacker then attempts to create memory-management pressure and timing conditions involving transparent huge pages, folio splitting, migration entries, and concurrent unmapping or zapping of page-table entries. If the race is won, the kernel may read inconsistent folio state because the required memory-ordering barrier is missing. This can trigger a kernel warning or BUG condition in the folio/migration-entry handling path. On systems configured to panic on kernel warnings, or on kernel versions where the condition reaches a BUG_ON()-style failure path, the result can be a kernel panic and denial of service. Exploitation is timing-sensitive and high-complexity, and no named threat actors or active exploitation campaigns are currently identified from the provided intelligence.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix adding the missing smp_rmb() barrier for migration entries in softleaf_to_folio() and softleaf_to_page(). Because no exact fixed package versions were provided, use the latest security-supported kernel from the relevant Linux distribution or vendor and verify that the vendor advisory includes the fix for CVE-2026-31466 or the corresponding upstream mm/huge_memory patch. Where immediate patching is not possible, reduce exposure by limiting local code execution by untrusted users, restricting shell access, hardening container isolation, minimizing workloads that allow untrusted memory-stress behavior, and reviewing whether panic_on_warn is appropriate for availability-sensitive systems. Mitigations should be treated as risk reduction only; the durable fix is a patched kernel followed by reboot into that kernel.

How to confirm the fix worked

Confirm exposure by identifying the running kernel version with uname -a or equivalent fleet inventory and comparing it against the distribution/vendor advisory for this issue. Confirm remediation by verifying that systems are booted into a patched kernel, not merely that a patched package is installed. If building or validating from source, confirm the memory-management code includes the added read memory barrier in the migration-entry path for softleaf_to_folio() and softleaf_to_page(). After remediation, run representative memory-intensive workloads and review kernel logs for absence of recurring warnings involving pfn_swap_entry_folio(), softleaf_to_folio(), softleaf_to_page(), migration entries, or folio lock assertions. For high-availability environments, also validate that reboot orchestration, live migration, or node draining completed successfully after kernel updates.

Typical attack path

1. Obtain local low-privileged code execution on an affected Linux host.
2. Run a workload designed to manipulate memory mappings, transparent huge pages, and folio splitting behavior.
3. Create concurrent memory pressure and page-table changes that increase the chance of racing deferred_split_scan(), split_folio(), and zap_nonpresent_ptes().
4. Trigger the missing memory-barrier condition in softleaf_to_folio() or softleaf_to_page() when a migration entry references a tail page.
5. Cause the kernel to observe inconsistent folio lock state and emit VM_WARN_ON_ONCE() or hit a BUG/panic path.
6. Leverage the resulting kernel warning escalation or crash to deny service to workloads on the host.

How to detect it

To assess possible prior exploitation or triggering, review kernel logs and crash artifacts rather than network telemetry, because this is a local kernel race with no inherent remote protocol signature. Search journald, syslog, dmesg archives, /var/log/kern.log, /var/log/messages, kdump/vmcore records, crash dumps, and monitoring alerts for kernel warnings or panics involving folio locking, migration entries, transparent huge page splitting, pfn_swap_entry_folio(), softleaf_to_folio(), softleaf_to_page(), zap_nonpresent_ptes(), deferred_split_scan(), or split_folio(). Correlate any matching kernel warnings, BUG splats, oopses, or unexplained reboots with local user activity, container workloads, memory-stress jobs, CI tasks, and processes that allocate, unmap, migrate, or pressure large memory regions. Look for clusters of repeated warnings followed by node reboots, watchdog resets, kernel panics, or workload evictions. Absence of logs does not prove non-exploitation if persistent kernel logging, kdump, or remote log forwarding was not enabled before a crash.

• VM_WARN_ON_ONCE(!folio_test_locked(folio))
• pfn_swap_entry_folio
• softleaf_to_folio
• softleaf_to_page
• zap_nonpresent_ptes
• deferred_split_scan
• split_folio
• __split_folio_to_order
• unmap_folio
• migration entry
• folio isn't locked
• folio_test_locked
• BUG: kernel
• kernel BUG
• Kernel panic
• panic_on_warn
• /var/log/kern.log
• /var/log/messages
• /var/crash
• /proc/sys/kernel/panic_on_warn

What your security team should do

• Prioritize patching Linux systems that allow local user access, run untrusted containers, host shared workloads, or support critical production services where a kernel crash would cause material downtime.
• Inventory affected kernel versions across servers, container hosts, virtualization nodes, appliances, and embedded Linux deployments, and map each to the relevant vendor-fixed kernel package.
• Reboot systems after kernel package updates and verify the active running kernel is the patched version.
• Review kernel panic settings such as panic_on_warn on systems where availability is more important than immediate crash-on-warning behavior, while balancing operational and forensic requirements.
• Restrict local code execution paths for untrusted users until patching is complete, including shell access, CI runner permissions, container privileges, and workload scheduling on sensitive hosts.
• Monitor kernel logs for folio, huge page, migration-entry, and VM warning messages that may indicate attempted triggering or unstable affected behavior.
• Because EPSS is very low, exploit maturity is none, and the CVE is not in KEV, treat this as a scheduled-but-important kernel maintenance item unless the environment has high local multi-tenant exposure or strict availability requirements.