CVE-2026-93075
NoneCVSS
—
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's handling of certain memory devices can let an attacker crash the system or run malicious code if devices are repeatedly attached and detached.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- High
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Failure to clear stale pgmap->ops and pgmap->owner pointers on fsdev unbind leaves a shared long-lived pgmap with references to possibly-freed fsdev_pagemap_ops handlers; subsequent memory_failure calls dispatch through those handlers, producing a use-after-free.
Why it matters to the business
Kernel crashes or arbitrary code execution on systems that dynamically attach and detach persistent-memory or DAX devices, potentially causing downtime or full host compromise in storage or virtualization environments.
How an attack unfolds
An attacker with the ability to bind and unbind fsdev devices arranges for a static pgmap to retain stale fsdev handlers, then triggers a memory_failure event (via hardware error, injected fault, or another module) that dereferences the now-freed or unloaded handler, leading to control-flow hijacking.
How to fix it
Apply the upstream fix that registers a devm action to clear pgmap->ops and pgmap->owner on unbind; rebuild and deploy a kernel containing the patch for all affected distributions.
How to confirm the fix worked
Confirm the patch is present by inspecting fsdev_dax_probe for the devm action registration; attempt bind/unbind cycles on static DAX devices followed by memory_failure injection and verify no use-after-free occurs.
Typical attack path
- Obtain privileges sufficient to load/unload fsdev and manipulate DAX device bindings.
- Bind an fsdev device to a static pgmap, then unbind it, leaving stale ops/owner pointers.
- Unload the fsdev module or rebind the device under a different driver that does not install a memory_failure handler.
- Trigger a memory_failure on the affected pgmap range.
- Execute code via the dangling handler pointer.
How to detect it
Review kernel logs for use-after-free reports or page-faults involving pgmap or fsdev_pagemap_ops after device unbind events; correlate with dmesg entries showing fsdev module unload or MEMORY_DEVICE_GENERIC rebinds.
What your security team should do
- Prioritize kernel updates on hosts that use persistent memory or DAX storage.
- Audit systems for custom or out-of-tree fsdev or dax drivers that may bypass the fix.
- Monitor for unusual device bind/unbind activity on production storage nodes.
The record
In the Linux kernel, the following vulnerability has been resolved: dax/fsdev: clear pgmap ops and owner on unbind fsdev_dax_probe() sets pgmap->ops = &fsdev_pagemap_ops and pgmap->owner = dev_dax, but nothing ever clears them. For a dynamic device the pgmap is devm-allocated and freed on unbind, so this is harmless. For a static device the pgmap is the shared, long-lived one owned by the dax bus (kill_dev_dax() only NULLs dev_dax->pgmap for the non-static case), and device.c's probe sets only pgmap->type, never clearing ops/owner. So after fsdev unbinds a static device the stale fsdev_pagemap_ops survives on the shared pgmap. If the device is then rebound to device_dax (MEMORY_DEVICE_GENERIC, which installs no ->memory_failure), or the fsdev_dax module is unloaded, a subsequent memory_failure on that pgmap dispatches through the stale -- and possibly freed -- handler. Register a devm action that clears pgmap->ops and pgmap->owner on unbind, symmetric with setting them at probe, so the pgmap carries no fsdev state once fsdev is detached.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|