Cloudanix VulnDB

CVE-2026-93073

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A timing flaw inside the Linux kernel handling of certain memory devices can cause the whole system to crash unexpectedly during routine operations.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in dax_holder_notify_failure() where holder_ops is read twice without READ_ONCE(), allowing a concurrent fs_put_dax() to clear the pointer between the NULL check and the indirect call, resulting in a NULL dereference.

Why it matters to the business

Systems using DAX for persistent memory may experience kernel crashes or denial of service during normal filesystem operations, potentially disrupting workloads on affected Linux kernels until patched.

How an attack unfolds

An attacker with local access triggers filesystem operations that invoke fs_put_dax() concurrently with dax_holder_notify_failure(), racing the unsynchronized reads of holder_ops to induce a NULL pointer dereference and kernel panic.

How to fix it

Update to a Linux kernel containing the fix that fetches holder_ops once with READ_ONCE(); apply the patch or newer stable release that resolves the double-read race in dax_holder_notify_failure().

How to confirm the fix worked

Inspect the dax.c source for the READ_ONCE() wrapper around the holder_ops load, recompile and boot the updated kernel, then exercise DAX holder failure paths to confirm absence of the race.

Typical attack path

  1. Mount a DAX-enabled filesystem on persistent memory
  2. Trigger concurrent holder operations and fs_put_dax calls via user-space I/O or unmount sequences
  3. Exploit the window between the two unsynchronized reads of holder_ops to dereference NULL

How to detect it

Search kernel logs and crash dumps for oops or panic messages referencing dax_holder_notify_failure or holder_ops dereference; correlate with concurrent DAX filesystem unmount or failure events.

What your security team should do

  • Prioritize kernel updates for any systems exposing DAX or persistent memory filesystems
  • Monitor kernel logs for NULL pointer dereference oops in dax-related functions
  • Restrict unprivileged local access on high-value DAX hosts until patched

The record

In the Linux kernel, the following vulnerability has been resolved: dax: read holder_ops once in dax_holder_notify_failure() dax_holder_notify_failure() reads dax_dev->holder_ops twice without READ_ONCE() -- once for the NULL check and once for the indirect notify_failure() call. A concurrent fs_put_dax() can clear holder_ops between the two reads, so the check can observe a non-NULL pointer while the call dereferences NULL. (kill_dax() also clears holder_ops, but only after synchronize_srcu(), so it cannot race a reader that is inside dax_read_lock(); fs_put_dax() does no such synchronization.) Fetch holder_ops once into a local with READ_ONCE() so the NULL check and the indirect call observe the same value.

Affected packages

Ecosystem Package Introduced Fixed