Cloudanix VulnDB

CVE-2026-93076

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug in handling certain high-speed storage devices could cause crashes or memory errors when those devices are switched between different drivers.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Other
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Stale pgmap->vmemmap_shift value from prior device_dax binding persists on shared pgmap when rebinding static DAX device to fsdev_dax, causing devm_memremap_pages to build vmemmap using incorrect shift instead of order-0 folios required by fsdev.

Why it matters to the business

Systems using static DAX devices risk kernel instability, invalid memory mappings, or data corruption during device rebinding operations; low exploitability but affects specialized storage/memory configurations.

How an attack unfolds

An attacker with local access rebinds a static DAX device from device_dax to fsdev_dax, leaving the stale vmemmap_shift intact so subsequent memory remapping operations use wrong folio sizes and trigger memory corruption or crashes.

How to fix it

Apply the upstream kernel patch that explicitly zeros pgmap->vmemmap_shift before devm_memremap_pages for static DAX devices; rebuild and deploy updated kernel images to all affected hosts.

How to confirm the fix worked

Confirm presence of the fix by inspecting kernel source for the vmemmap_shift clearing logic before devm_memremap_pages, or verify updated kernel version contains the dax/fsdev commit; test rebinding static DAX devices to fsdev_dax and inspect resulting vmemmap.

Typical attack path

  1. Obtain local access on Linux system with DAX support
  2. Identify and unbind static DAX device currently attached to device_dax
  3. Rebind device to fsdev_dax without clearing pgmap state
  4. Trigger memory operations that rely on the incorrectly built vmemmap

How to detect it

Search kernel logs and dmesg for DAX, pgmap, or vmemmap related warnings, oops, or page faults occurring after device rebinding; review audit logs for device_dax to fsdev_dax transitions on systems with static DAX.

What your security team should do

  • Prioritize patching kernel on systems exposing DAX devices to untrusted users or workloads
  • Audit DAX device usage and binding scripts for static device rebinding patterns
  • Monitor kernel logs for DAX/pgmap related oops or warnings until patches are deployed

The record

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.

Affected packages

Ecosystem Package Introduced Fixed