CVE-2026-93074: dax/fsdev: use __va(phys) for kaddr in direct_access
In the Linux kernel, the following vulnerability has been resolved:
dax/fsdev: use va(phys) for kaddr in directaccess
Use va(phys) instead of virtaddr + linearoffset for the kaddr return in fsdevdaxdirectaccess(). The previous code added a device-linear byte offset to virtaddr (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 daxpgofftophys() is correct for any range layout because the direct map translates each physical address independently.
This leaves devdax->virtaddr write-only, so remove the field (suggested by Dave Jiang).
Event History
Frequently Asked Questions
Which systems are exposed to the incorrect address calculation?
Systems using fsdev DAX with a device that has multiple physical ranges separated by gaps are exposed. The incorrect arithmetic can produce a kernel virtual address that crosses a physical gap.
What condition triggers the faulty mapping?
A direct-access operation must resolve an offset into a later physical range on a multi-range device with gaps. The previous implementation derived the address by adding a linear device offset to the first range's virtual address instead of translating the resolved physical address independently.
How can I determine whether the fix is present?
Check whether __fsdev_dax_direct_access() returns kaddr using __va(phys), with phys obtained from dax_pgoff_to_phys(). The fix also removes the dev_dax->virt_addr field because it is no longer needed for reads.