CVE-2026-98259 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
fs/dax: check zero or empty entry before converting xarray entry
Calling dax_to_folio() with empty entry causes kernel panic below when booting a VM with DAX enabled storage.
This patch checks empty entry before calling dax_to_folio() on dax_associate_entry(), dax_disassociate_entry(), and dax_busy_page().
Commit 98c183a4fccf ("fs/dax: don't disassociate zero page entries") added guards in the associate and disassociate paths, but the guards still come after dax_to_folio(), and dax_busy_page() still has the same problem.
[ 0.737679] EXT4-fs (pmem0p1): mounted filesystem 79676804-7c8b-491a-b2a6-9bae3c72af70 ro with ordered data mode. Quota mode: disabled.
[ 0.737891] VFS: Mounted root (ext4 filesystem) readonly on device 259:1.
[ 0.739119] devtmpfs: mounted
[ 0.739476] Freeing unused kernel memory: 1920K
[ 0.740156] Run /sbin/init as init process
[ 0.740229] with arguments:
[ 0.740286] /sbin/init
[ 0.740321] with environment:
[ 0.740369] HOME=/
[ 0.740400] TERM=linux
[ 0.743162] Unable to handle kernel paging request at virtual address fffffdffbf000008
[ 0.743285] Mem abort info:
[ 0.743316] ESR = 0x0000000096000006
[ 0.743371] EC = 0x25: DABT (current EL), IL = 32 bits
[ 0.743444] SET = 0, FnV = 0
[ 0.743489] EA = 0, S1PTW = 0
[ 0.743545] FSC = 0x06: level 2 translation fault
[ 0.743610] Data abort info:
[ 0.743656] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[ 0.743720] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 0.743785] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 0.743848] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000b9d17000
[ 0.743931] [fffffdffbf000008] pgd=10000000bfa3d403, p4d=10000000bfa3d403, pud=1000000040bfe403, pmd=0000000000000000
[ 0.744070] Internal error: Oops: 0000000096000006 [#1] SMP
[ 0.748888] CPU: 0 UID: 0 PID: 1 Comm: init Not tainted 6.18.4 #1 NONE
[ 0.749421] pstate: 004000c5 (nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.749969] pc : dax_disassociate_entry.constprop.0+0x20/0x50
[ 0.750444] lr : dax_insert_entry+0xcc/0x408
[ 0.750802] sp : ffff80008000b9e0
[ 0.751083] x29: ffff80008000b9e0 x28: 0000000000000000 x27: 0000000000000000
[ 0.751682] x26: 0000000001963d01 x25: ffff0000004f7d90 x24: 0000000000000000
[ 0.752264] x23: 0000000000000000 x22: ffff80008000bcc8 x21: 0000000000000011
[ 0.752836] x20: ffff80008000ba90 x19: 0000000001963d01 x18: 0000000000000000
[ 0.753407] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 0.753970] x14: ffffbf3154b9ae70 x13: 0000000000000000 x12: ffffbf3154b9ae70
[ 0.754548] x11: ffffffffffffffff x10: 0000000000000000 x9 : 0000000000000000
[ 0.755122] x8 : 000000000000000d x7 : 000000000000001f x6 : 0000000000000000
[ 0.755707] x5 : 0000000000000000 x4 : 0000000000000000 x3 : fffffdffc0000000
[ 0.756287] x2 : 0000000000000008 x1 : 0000000040000000 x0 : fffffdffbf000000
[ 0.756871] Call trace:
[ 0.757107] dax_disassociate_entry.constprop.0+0x20/0x50 (P)
[ 0.757592] dax_iomap_pte_fault+0x4fc/0x808
[ 0.757951] dax_iomap_fault+0x28/0x30
[ 0.758258] ext4_dax_huge_fault+0x80/0x2dc
[ 0.758594] ext4_dax_fault+0x10/0x3c
[ 0.758892] __do_fault+0x38/0x12c
[ 0.759175] __handle_mm_fault+0x530/0xcf0
[ 0.759518] handle_mm_fault+0xe4/0x230
[ 0.759833] do_page_fault+0x17c/0x4dc
[ 0.760144] do_translation_fault+0x30/0x38
[ 0.760483] do_mem_abort+0x40/0x8c
[ 0.760771] el0_ia+0x4c/0x170
[ 0.761032] el0t_64_sync_handler+0xd8/0xdc
[ 0.761371] el0t_64_sync+0x168/0x16c
[ 0.761677] Code: f9453021 f2dfbfe3 cb813080 8b001860 (f9400401)
[ 0.762168] ---[ end trace 0000000000000000 ]---
[ 0.762550] note: init[1] exited with irqs disabled
[ 0.762631] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel contains a critical flaw within the Direct Access, or DAX, subsystem that leads to a system crash during early boot when virtual machines utilize persistent memory storage. This vulnerability manifests as an unrecoverable kernel panic triggered by a null pointer dereference occurring in the dax_disassociate_entry function. The root cause lies in the improper handling of empty or zero-valued entries within the xarray data structure used for page management. When the system attempts to associate or disassociate these specific types of entries, it invokes helper functions such as dax_to_folio and dax_busy_page without first verifying that the entry contains valid data. This oversight results in the kernel attempting to access memory at an invalid virtual address, specifically fffffdffbf000008, which triggers a level two translation fault on ARM64 architectures. The resulting exception causes the init process to terminate abnormally with exit code zeroxb, forcing the kernel into panic mode because it cannot proceed without its primary initialization process.
This issue represents a classic instance of improper input validation leading to resource management errors within the operating system core. From a vulnerability classification perspective, this aligns closely with CWE-476, which denotes a null pointer dereference, and CWE-20, indicating improper input validation where the software fails to verify that an entry is non-empty before processing it. The technical flaw stems from a regression introduced by commit 98c183a4fccf, titled fs/dax: don't disassociate zero page entries. While that previous patch attempted to mitigate similar issues by adding guards in the associate and disassociate paths, those safeguards were implemented incorrectly. They were placed after the call to dax_to_folio rather than before it, meaning the dangerous function was still executed with invalid data. Furthermore, the related function dax_busy_page remained unpatched, retaining the same vulnerability pattern where empty entries are processed without prior validation checks.
The operational impact of this vulnerability is severe for environments relying on DAX-enabled storage devices such as Intel Optane or other persistent memory modules configured via ext4 filesystems with ordered data mode. During system boot, particularly in virtualized guest operating systems, the kernel attempts to map pages from these high-performance storage backends. When it encounters an empty xarray entry representing a hole in the file space rather than actual allocated blocks, the flawed logic proceeds to dereference pointers associated with that non-existent folio structure. This causes immediate system instability and prevents successful boot completion. For production systems, this could lead to denial of service through repeated crashes or require manual intervention to disable DAX features, thereby negating the performance benefits provided by persistent memory hardware.
Mitigation strategies primarily involve applying the upstream kernel patch that corrects the order of operations within these functions. The fix requires moving the checks for zero or empty entries to precede any calls to dax_to_folio and dax_busy_page in both dax_associate_entry, dax_disassociate_entry, and dax_busy_page routines. This ensures that if an entry is found to be empty, the function returns early without attempting to access invalid memory structures. Administrators running affected kernel versions should update their systems to a patched release immediately. In cases where immediate patching is not feasible due to compatibility constraints or testing requirements, disabling Direct Access support for persistent memory devices serves as an effective workaround. This can typically be achieved by removing the dax mount option from filesystem configurations in /etc/fstab or adjusting boot parameters to prevent the kernel from initializing DAX capabilities during startup, thus avoiding the code path that triggers the panic entirely.