CVE-2026-93076 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
dax/fsdev: clear vmemmap_shift when binding static pgmap
Clear pgmap->vmemmap_shift for static DAX devices. When rebinding a static device from device_dax (which may set vmemmap_shift based on alignment) to fsdev_dax, the stale vmemmap_shift persists on the shared pgmap. Explicitly zero it before devm_memremap_pages() so the vmemmap is built for order-0 folios as fsdev requires.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's Direct Access (DAX) subsystem provides a mechanism for applications to map persistent memory regions directly into their address space, bypassing the page cache and CPU caches to achieve low-latency access. This functionality relies heavily on how the kernel manages virtual memory mappings and the associated vmemmap structures, which describe physical pages in the virtual memory system. A specific vulnerability arises within the interaction between static DAX devices managed by device_dax and filesystem-backed DAX devices handled by fsdev_dax. The core issue involves the improper handling of the vmemmap_shift field during the rebinding or reconfiguration of a persistent memory region from one driver context to another, specifically when transitioning from a device-dax provider to an fsdev-dax consumer.
The technical flaw stems from how the pgmap structure, which describes page mappings for DAX regions, retains state information across different binding contexts. When a static device is initially bound via device_dax, the kernel may set vmemmap_shift based on specific alignment requirements or hardware capabilities to optimize memory mapping efficiency. However, when this same physical region is subsequently rebound to fsdev_dax, which manages persistent memory for filesystem operations, the stale value of vmemmap_shift persists in the shared pgmap structure. This persistence occurs because the code did not explicitly clear or reset this field before initializing the new mapping context. Consequently, the kernel attempts to build the vmemmap using an incorrect page order assumption that does not align with fsdev_dax's requirements for handling folios at order-0 granularity.
This misconfiguration leads to significant operational impacts on system stability and data integrity. By failing to clear vmemmap_shift, the kernel may allocate or map memory structures incorrectly, potentially causing alignment mismatches between the virtual memory layout and the physical persistent memory architecture. Such errors can manifest as kernel panics, segmentation faults in applications attempting DAX access, or silent corruption of metadata if the mapping assumptions about page boundaries are violated. In severe cases, this could allow a local user with appropriate privileges to trigger these conditions during device reconfiguration, leading to denial-of-service scenarios where the system becomes unresponsive due to fatal kernel errors triggered by improper memory management operations within the DAX subsystem.
From a vulnerability classification perspective, this issue aligns with CWE-20 Improper Input Validation and CWE-665 Incorrect Initialization, as the code fails to properly initialize or reset state variables when transitioning between different operational contexts. In terms of attack vectors, it relates to ATT&CK technique T1499 Endpoint Denial of Service via resource exhaustion or instability, although primarily affecting system stability rather than direct resource consumption by an attacker. The flaw represents a logic error in the lifecycle management of kernel memory mappings where state from one driver binding is not correctly sanitized before being applied to another context with different constraints.
Mitigation strategies for this vulnerability involve applying the specific patch that addresses the root cause within the Linux kernel source code. System administrators and developers should ensure they are running patched versions of the Linux kernel that include fixes for dax/fsdev vmemmap_shift handling. For environments where immediate patching is not feasible, restricting access to device_dax rebinding operations or avoiding dynamic reconfiguration of persistent memory regions from static devices can reduce exposure. Additionally, rigorous testing of DAX configurations during system updates and hardware changes helps identify potential instability before it impacts production workloads. Maintaining up-to-date kernel versions remains the most effective defense against such low-level memory management flaws that compromise system reliability.