Cloudanix VulnDB

CVE-2026-98259

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel can crash servers that use certain high-speed storage devices during startup, preventing the machine from finishing its boot process.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Missing guard before dax_to_folio() on empty xarray entries in dax_associate_entry, dax_disassociate_entry, and dax_busy_page allows invalid memory dereference, producing a level-2 translation fault and kernel panic.

Why it matters to the business

Systems configured with DAX-enabled persistent memory storage may fail to complete boot, resulting in unplanned downtime and loss of availability for workloads relying on those devices.

How an attack unfolds

An attacker with the ability to present a DAX-backed block device during early boot can trigger the empty-entry path in the DAX fault handler; the kernel then calls dax_to_folio on an uninitialized entry, dereferences an invalid address, and panics before userspace init completes.

How to fix it

Apply the upstream fix that adds empty-entry checks before dax_to_folio calls in the three affected DAX functions; update to a kernel version containing commit 98c183a4fccf plus the additional guards described in the resolution.

How to confirm the fix worked

Boot a test system with DAX storage and confirm the kernel reaches userspace without the "Unable to handle kernel paging request" fault in dax_disassociate_entry; inspect dmesg for absence of the panic signature.

Typical attack path

  1. Attach or configure a DAX-capable pmem device visible at boot
  2. Boot the kernel with the device mounted as root or data volume using DAX
  3. Kernel reaches ext4_dax_fault during page-fault handling of init process
  4. dax_iomap_pte_fault calls dax_disassociate_entry with empty entry
  5. dax_to_folio dereferences invalid address, triggering data abort and panic

How to detect it

Search kernel logs and boot logs for the exact panic strings "Unable to handle kernel paging request at virtual address fffffdffbf000008" and "dax_disassociate_entry.constprop.0+0x20/0x50"; correlate with presence of pmem or DAX device nodes in dmesg.

  • dax_disassociate_entry.constprop.0+0x20/0x50
  • Unable to handle kernel paging request at virtual address fffffdffbf000008
  • ESR = 0x0000000096000006
  • Kernel panic - not syncing: Attempted to kill init!

What your security team should do

  • Prioritize kernel updates on all hosts using DAX or persistent-memory block devices
  • Temporarily disable DAX mounts on affected kernels until patches are applied
  • Add boot-time monitoring for DAX-related oops and kernel panics to existing alerting

The record

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

Affected packages

Ecosystem Package Introduced Fixed