Cloudanix VulnDB

CVE-2026-93074

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug can give local users the ability to reach the wrong memory on certain storage devices, risking crashes or unauthorized access.

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

What it actually does

Incorrect kernel virtual address calculation in __fsdev_dax_direct_access() for multi-range DAX devices that have physical address gaps, causing the linear offset arithmetic to produce an invalid kaddr and resulting in memory corruption or invalid access.

Why it matters to the business

Systems using DAX or persistent memory may experience kernel crashes, data corruption, or local privilege escalation, increasing downtime and risk on affected Linux deployments.

How an attack unfolds

A local attacker with access to a system containing a multi-range DAX device triggers __fsdev_dax_direct_access() so that the faulty virt_addr + linear_offset arithmetic crosses a physical gap and returns a wrong kernel address, enabling subsequent memory corruption primitives.

How to fix it

Apply the upstream kernel commit that replaces virt_addr + linear_offset with __va(phys) from dax_pgoff_to_phys() and removes the now-unused dev_dax->virt_addr field; rebuild and reboot to the corrected kernel.

How to confirm the fix worked

Inspect the source of __fsdev_dax_direct_access() to confirm use of __va(phys); verify that dev_dax->virt_addr field has been removed; test direct_access on a multi-range DAX device and confirm correct kaddr values.

Typical attack path

  1. Obtain local user access on a Linux system with a multi-range DAX device
  2. Arrange or trigger a direct_access operation on the affected fsdev DAX path
  3. Force the linear offset calculation to reference an address across a physical gap
  4. Use the resulting invalid kernel virtual address to corrupt memory or escalate privileges

How to detect it

Search kernel logs for DAX-related oops, page faults, or warnings mentioning fsdev or direct_access; examine crash dumps for invalid kernel virtual addresses originating from dax_pgoff_to_phys paths.

What your security team should do

  • Prioritize kernel updates on all systems exposing DAX or persistent memory
  • Review and restrict local access to systems with multi-range DAX devices until patched
  • Monitor vendor advisories for backported fixes in distribution kernels

The record

In the Linux kernel, the following vulnerability has been resolved: dax/fsdev: use __va(phys) for kaddr in direct_access Use __va(phys) instead of virt_addr + linear_offset for the kaddr return in __fsdev_dax_direct_access(). The previous code added a device-linear byte offset to virt_addr (which is __va of ranges[0]), but for multi-range devices with physical gaps between ranges, this linear arithmetic crosses the gap and produces a wrong kernel virtual address. Using __va(phys) where phys comes from dax_pgoff_to_phys() is correct for any range layout because the direct map translates each physical address independently. This leaves dev_dax->virt_addr write-only, so remove the field (suggested by Dave Jiang).

Affected packages

Ecosystem Package Introduced Fixed