CVE-2026-31466: Linux Kernel Race Condition Vulnerability

CVE-2026-31466 Overview

CVE-2026-31466 is a race condition vulnerability in the Linux kernel's memory management subsystem, specifically affecting the huge memory (Transparent Huge Pages) handling in mm/huge_memory. The vulnerability exists in the softleaf_to_folio() function where a missing memory barrier allows a race condition between folio splitting operations and page table entry zapping, potentially leading to system instability and kernel warnings.

The issue was discovered on arm64 servers where a folio obtained from a migration entry is not properly locked in softleaf_to_folio(). This race condition occurs when mTHP (multi-size Transparent Huge Pages) splitting and zap_nonpresent_ptes() execute concurrently, caused by a missing smp_rmb() memory barrier that should pair with an existing smp_wmb() in __split_folio_to_order().

Critical Impact

Race condition in Linux kernel memory management can trigger VM_WARN_ON_ONCE() or BUG_ON() assertions, potentially causing kernel panics and system instability on arm64 and other architectures using Transparent Huge Pages.

Affected Products

• Linux kernel versions with mTHP support
• Systems running arm64 architecture with Transparent Huge Pages enabled
• Linux kernel versions prior to the security patches (see kernel commit references)

Discovery Timeline

• 2026-04-22 - CVE CVE-2026-31466 published to NVD
• 2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-31466

Vulnerability Analysis

This race condition vulnerability occurs in the interaction between two kernel subsystems: the deferred folio splitting mechanism and the page table entry cleanup process. The fundamental issue stems from improper memory ordering between concurrent CPU operations.

When deferred_split_scan() executes on CPU0, it locks a folio and begins the splitting process through split_folio(). This involves unmapping the folio and changing page table entries (PTEs) to migration entries. During __split_folio_to_order(), page flags (including PG_locked) are set for tail pages, followed by an smp_wmb() (write memory barrier) before preparing the compound page structure for tail pages.

Concurrently, on CPU1, zap_nonpresent_ptes() may call softleaf_to_folio() which retrieves a folio from a migration entry. Without a corresponding smp_rmb() (read memory barrier), CPU1 may observe the updated compound_head of a tail page before observing the updated page flags, including the lock state.

This memory ordering violation results in VM_WARN_ON_ONCE(!folio_test_locked(folio)) being triggered in pfn_swap_entry_folio() because the folio appears to be undergoing modification without holding the folio lock. In kernel versions prior to commit 93976a20345b ("mm: eliminate further swapops predicates"), this condition would trigger a BUG_ON(), causing a kernel panic.

Root Cause

The root cause is a missing smp_rmb() memory barrier in softleaf_to_folio() that should pair with the smp_wmb() in __split_folio_to_order(). Memory barriers are essential in concurrent programming to ensure proper ordering of memory operations across multiple CPUs. The smp_wmb() ensures that writes to page flags are visible before writes to the compound page structure. However, without the corresponding smp_rmb() on the reading side, a concurrent reader may observe these writes in a different order, leading to the observed race condition.

Attack Vector

This is a local kernel vulnerability that can be triggered through normal memory management operations on systems using Transparent Huge Pages. The race condition requires specific timing between:

1. A process triggering deferred folio splitting (memory pressure scenarios)
2. Concurrent unmapping of memory regions containing migration entries

While this vulnerability primarily manifests as a reliability and stability issue rather than a security exploit, race conditions in kernel memory management can potentially be leveraged for more severe attacks. The condition could be triggered more reliably by:

• Creating memory pressure to trigger deferred split scans
• Simultaneously performing memory unmapping operations
• Running workloads that heavily utilize mTHP on arm64 systems

The race window exists between the setting of page flags in __split_folio_to_order() and the reading of those flags in softleaf_to_folio() without proper memory barrier synchronization.

Detection Methods for CVE-2026-31466

Indicators of Compromise

• Kernel log messages containing VM_WARN_ON_ONCE warnings related to folio_test_locked failures
• Kernel warnings in pfn_swap_entry_folio() function
• Unexpected BUG_ON() kernel panics on older kernel versions (pre-v6.19-rc1)
• System instability on arm64 servers under memory pressure with THP enabled

Detection Strategies

• Monitor kernel logs (dmesg, /var/log/kern.log) for warnings containing softleaf_to_folio, zap_nonpresent_ptes, or pfn_swap_entry_folio
• Enable kernel ftrace or perf tracing on memory management functions to detect anomalous race conditions
• Deploy kernel live patching detection mechanisms to identify systems running vulnerable kernel versions
• Utilize SentinelOne's kernel-level monitoring to detect memory management anomalies and kernel warning conditions

Monitoring Recommendations

• Configure syslog alerting for kernel warning messages matching the race condition patterns
• Implement automated kernel version auditing across infrastructure to identify unpatched systems
• Monitor system stability metrics on arm64 servers with Transparent Huge Pages enabled
• Set up crash dump analysis pipelines to capture and analyze any kernel panics related to memory management

How to Mitigate CVE-2026-31466

Immediate Actions Required

• Update Linux kernel to a patched version containing the memory barrier fix
• Review and prioritize patching for arm64 servers and systems heavily utilizing Transparent Huge Pages
• Consider temporarily disabling THP on critical systems until patches can be applied: echo never > /sys/kernel/mm/transparent_hugepage/enabled
• Monitor affected systems for kernel warnings and instability while awaiting patch deployment

Patch Information

The fix adds the missing smp_rmb() memory barrier in softleaf_to_folio() and softleaf_to_page() when processing migration entries. Multiple kernel stable branches have received patches:

• Kernel Commit 426ee107
• Kernel Commit 4c5e7f0f
• Kernel Commit 722cfaf6
• Kernel Commit 7ad1997b
• Kernel Commit 7ddcf4a2
• Kernel Commit 8bfb8414
• Kernel Commit b8c49ad8
• Kernel Commit f1acf588

Workarounds

• Disable Transparent Huge Pages system-wide as a temporary mitigation until patching is complete
• Reduce memory pressure scenarios that trigger deferred split scans
• Consider limiting workloads on affected arm64 systems until patches are deployed
• Implement kernel live patching solutions where available for faster remediation

# Temporary workaround: Disable Transparent Huge Pages
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# To make persistent across reboots, add to /etc/rc.local or create systemd service
# Verify THP status
cat /sys/kernel/mm/transparent_hugepage/enabled