CVE-2026-31575: Linux Kernel Race Condition Vulnerability

CVE-2026-31575 Overview

A race condition vulnerability has been identified in the Linux kernel's userfaultfd subsystem, specifically affecting hugetlb fault mutex hash calculation in the mfill_atomic_hugetlb() function. The vulnerability stems from a mismatch between page index calculation units, where linear_page_index() returns indices in PAGE_SIZE units while hugetlb_fault_mutex_hash() expects indices in huge page units. This discrepancy allows different addresses within the same huge page to produce different hash values, leading to the use of different mutexes for the same huge page and enabling race conditions between faulting threads.

Critical Impact
Successful exploitation can corrupt the reservation map and trigger a kernel BUG_ON in resv_map_release(), resulting in a denial of service condition affecting system availability.

Affected Products

Linux Kernel (multiple versions)

Discovery Timeline

2026-04-24 - CVE CVE-2026-31575 published to NVD
2026-04-27 - Last updated in NVD database

Technical Details for CVE-2026-31575

Vulnerability Analysis

This vulnerability exists in the Linux kernel's memory management subsystem, specifically within the userfaultfd implementation for huge pages. The core issue involves incorrect page index granularity when calculating mutex hash values for hugetlb fault handling.

When the mfill_atomic_hugetlb() function processes page faults on huge pages, it uses linear_page_index() to determine the page index that will be passed to hugetlb_fault_mutex_hash(). However, these two functions operate with incompatible assumptions about page size units. The linear_page_index() function calculates indices based on standard PAGE_SIZE (typically 4KB), while hugetlb_fault_mutex_hash() expects indices that represent huge page boundaries (typically 2MB or 1GB).

This unit mismatch means that multiple 4KB-aligned addresses within the same 2MB huge page will calculate to different hash values, causing the kernel to select different mutexes for what should be protected as a single atomic unit. When multiple threads simultaneously fault on different addresses within the same huge page, they may acquire different mutexes instead of serializing through the same lock, creating a classic race condition.

Root Cause

The root cause is a semantic mismatch in the page index calculation between linear_page_index() and the expectations of hugetlb_fault_mutex_hash(). The linear_page_index() function was designed for standard page-sized operations and returns indices at PAGE_SIZE granularity, but it was incorrectly used in a context that requires huge page granularity. This API misuse allows concurrent threads to bypass the intended mutex serialization for huge page fault handling, leading to unsynchronized access to shared reservation map data structures.

Attack Vector

This vulnerability requires local access to the system and low-privilege user credentials. An attacker can exploit this vulnerability through the userfaultfd interface by deliberately triggering multiple page faults on different addresses within the same huge page from concurrent threads.

The exploitation scenario involves:

Allocating a huge page through the hugetlb subsystem
Registering the memory region with userfaultfd
Spawning multiple threads that simultaneously access different offsets within the same huge page
The race condition corrupts the reservation map data structure
When the reservation map is released, the corrupted state triggers a BUG_ON assertion, causing a kernel panic

This attack can be used to cause a denial of service by crashing the system. The local attack vector and requirement for user privileges limits the exploitability, though any authenticated user on a multi-user system could potentially trigger this condition.

Detection Methods for CVE-2026-31575

Indicators of Compromise

Kernel panic or BUG_ON messages referencing resv_map_release() in system logs
System crashes associated with hugetlb operations or userfaultfd activity
Kernel oops traces showing call stacks involving mfill_atomic_hugetlb() or hugetlb fault mutex functions

Detection Strategies

Monitor kernel logs for BUG_ON assertions or panic messages related to memory reservation maps
Track userfaultfd system call usage patterns, especially involving huge page regions
Implement audit rules for processes using UFFD_FEATURE_MISSING_HUGETLBFS capabilities
Deploy kernel module integrity monitoring to detect exploitation attempts

Monitoring Recommendations

Enable kernel crash dump collection to capture diagnostic information if the vulnerability is triggered
Configure alerting on kernel log messages containing resv_map or hugetlb_fault_mutex keywords
Monitor system stability metrics and correlate unexpected reboots with hugetlb memory usage patterns

How to Mitigate CVE-2026-31575

Immediate Actions Required

Apply the official kernel patches from the Linux kernel stable tree
If patching is not immediately possible, consider disabling userfaultfd for unprivileged users via sysctl vm.unprivileged_userfaultfd=0
Evaluate and restrict access to systems where huge page functionality is critical
Monitor affected systems for signs of exploitation until patches are applied

Patch Information

The Linux kernel maintainers have released patches that introduce a new function called hugetlb_linear_page_index() which correctly returns page indices in huge page granularity. This function replaces the inappropriate use of linear_page_index() in the mfill_atomic_hugetlb() code path.

Official patches are available from the kernel stable tree:

Workarounds

Disable unprivileged userfaultfd access by setting vm.unprivileged_userfaultfd=0 via sysctl
Restrict huge page allocation to trusted processes using cgroup memory controllers
Limit user access on multi-tenant systems until patches can be applied

bash

# Disable unprivileged userfaultfd access
echo 0 > /proc/sys/vm/unprivileged_userfaultfd
# Or make it persistent in sysctl.conf
echo "vm.unprivileged_userfaultfd = 0" >> /etc/sysctl.conf
sysctl -p