CVE Catalog

CVE-2026-93075

Unknown
Published: Translated: NVD NIST

Summary

In the Linux kernel, the dax/fsdev module's fsdev_dax_probe() sets pgmap->ops and pgmap->owner but never clears them on unbind. For a static device the pgmap is shared and long-lived, so after fsdev unbinds a static device the stale fsdev_pagemap_ops survives on the shared pgmap. A subsequent memory_failure can then dispatch through the stale, possibly freed handler.

Risk Assessment

This can lead to a use-after-free and kernel crash when handling memory errors after rebinding or unloading the fsdev_dax module.

Recommendation

Update the Linux kernel to a version with the fix. Avoid rebinding static DAX devices after fsdev unbind without updating.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS