Description
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.
Published: 2026-09-17
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Use‑After‑Free leading to potential arbitrary code execution in kernel mode
Action: Immediate Patch
AI Analysis

Impact

The Linux kernel change in the dax/fsdev driver leaves stale function pointer and owner references on the shared page map after a static device is unbound. When the device is later rebound or the module unloaded, a memory failure triggers the stale handler, which may reference freed memory. This use‑after‑free can allow arbitrary code execution in kernel mode. The likely attack vector is a local action that unbinds and rebinds a static DAX device or unloads the fsdev_dax module, actions that typically require root privileges or the ability to manipulate device bindings.

Affected Systems

All Linux kernel builds that include the dax/fsdev driver are potentially impacted. The vulnerability exists until the kernel patch that registers a devm action to clear pgmap->ops and pgmap->owner on unbind is applied.

Risk and Exploitability

The EPSS score is less than 1%, indicating a very low historical exploitation probability, and the vulnerability is not listed in CISA's KEV catalog. The likely exploitation scenario involves local privilege escalation, inferred from the need to unbind and rebind a static DAX device or unload the fsdev_dax module, actions that typically require root access. Because the flaw relies on device‑specific operations and memory failure conditions, a competent attacker could leverage it in a privileged environment. The risk is therefore considered moderate to high for affected systems that expose DAX devices.

Generated by OpenCVE AI on September 19, 2026 at 09:12 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that includes the patch implementing devm action to clear pgmap->ops and pgmap->owner on unbind (the commit that resolves the issue).
  • If an update is not immediately available, avoid unbinding static DAX devices or disable dynamic DAX device usage until the patch is applied.
  • As a temporary workaround, prevent unloading the fsdev_dax module while static devices are bound, or immediately remount devices with settings that block memory‑failure triggers on stale pointers.

Generated by OpenCVE AI on September 19, 2026 at 09:12 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 19 Sep 2026 09:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Thu, 17 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
Description 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.
Title dax/fsdev: clear pgmap ops and owner on unbind
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-17T16:10:57.699Z

Reserved: 2026-09-17T15:57:05.661Z

Link: CVE-2026-93075

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-17T17:18:01.440

Modified: 2026-09-17T17:18:01.440

Link: CVE-2026-93075

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-19T20:00:13Z

Weaknesses