CVE-2026-64187

What it actually does

This is a Linux kernel denial-of-service vulnerability in XFS log recovery. A crafted XFS filesystem log can contain a committed transaction item that has no associated regions, leaving recovery metadata with ri_cnt == 0 and ri_buf == NULL. During mount-time log recovery, xlog_recover_reorder_trans() calls ITEM_TYPE() and dereferences ri_buf[0], causing a NULL pointer dereference in kernel context. The practical result is a kernel oops/panic or mount-triggered system crash when the malformed XFS filesystem is recovered.

Why it matters to the business

Systems that mount untrusted or attacker-controlled XFS filesystems can be crashed, causing service interruption, failed boot or recovery operations, and potential downtime for hosts that automatically mount removable media, disk images, VM volumes, backup images, or storage presented by another party. The current public exploit maturity is listed as none, EPSS is low, and the issue is not in CISA KEV, so broad internet-scale exploitation is unlikely; however, the impact can be severe in environments where untrusted block devices or filesystem images are mounted automatically or by privileged workflows.

How an attack unfolds

An attacker prepares an XFS filesystem image or block device with a deliberately malformed journal/log. The crafted log includes a committed transaction where the first operation is only a transaction header and no regions are ultimately added before commit. The attacker then gets a vulnerable Linux system to mount the filesystem or otherwise trigger XFS log recovery, such as through a removable drive, VM disk, storage snapshot, backup image, forensic image, container/CI artifact, or other block device workflow. During xfs_log_mount() and recovery processing, the kernel queues the malformed log item with a NULL ri_buf. When xlog_recover_reorder_trans() attempts to inspect the item type, it dereferences the NULL buffer and faults in kernel mode, typically producing an oops or panic and denying service until the host is rebooted and the crafted filesystem is not mounted again.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the XFS fix for rejecting committed log items with no regions before recovery handlers dereference ri_buf[0]. Because no product-specific fixed versions were provided, use the security advisory and kernel package versions from the relevant Linux distribution or kernel supplier. Where immediate patching is not possible, reduce exposure by preventing automatic mounting of untrusted XFS filesystems, disabling desktop/server automount behavior for removable media where feasible, restricting who can attach or mount block devices and disk images, isolating forensic or recovery workflows in disposable VMs, and avoiding mounting untrusted XFS images on production systems. Do not rely on filesystem repair alone as a security boundary for hostile images; treat untrusted block devices as potentially kernel-attack input.

How to confirm the fix worked

Confirm that systems are running a kernel build containing the upstream XFS recovery change that fails recovery when a committed log item has no regions. Validate through vendor package metadata, changelogs, or advisory references rather than only checking the kernel version string, because fixes are often backported. Test representative systems by verifying that untrusted removable media and disk images are not automatically mounted. If safe test artifacts are available from a trusted source, validate in an isolated non-production VM that a malformed XFS log is rejected gracefully rather than causing a kernel oops or panic. Review boot and kernel logs after patching to confirm there are no recurring XFS recovery crashes involving xlog_recover_reorder_trans(), xlog_recover_commit_trans(), or NULL pointer dereferences during XFS mount.

Typical attack path

1. Create or modify an XFS filesystem image so its recovery log contains a committed transaction item with no regions.
2. Deliver the crafted filesystem through a medium the target may mount, such as a disk image, removable device, virtual disk, backup/snapshot, or attached block volume.
3. Cause or wait for the vulnerable Linux system to mount the XFS filesystem and enter log recovery.
4. The XFS recovery parser processes the malformed transaction and leaves an item with ri_cnt == 0 and ri_buf == NULL.
5. The kernel dereferences ri_buf[0] in xlog_recover_reorder_trans(), triggering a NULL pointer dereference.
6. The host experiences a kernel oops/panic or failed mount, resulting in denial of service.

How to detect it

Look for evidence that a system crashed or produced a kernel oops while mounting or recovering an XFS filesystem. Primary sources include kernel logs, systemd journal, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, hypervisor console logs, and storage or device-attachment audit logs. Focus on timelines where a new block device, removable drive, VM disk, disk image, backup image, or storage snapshot was attached shortly before a kernel fault. Useful artifacts include stack traces containing xlog_recover_reorder_trans(), xlog_recover_commit_trans(), xlog_recover_process_data(), xlog_do_recovery_pass(), xlog_recover(), xfs_log_mount(), or xfs_mountfs(); NULL pointer dereference messages; KASAN null-ptr-deref reports; and repeated failed boots or crashes tied to mounting the same XFS volume. If crash dumps are available, confirm whether the faulting instruction occurred in XFS log recovery and whether the mount target was an untrusted or newly introduced filesystem. There are no known threat actors or public exploitation campaigns associated with this issue from the provided data, so detection should emphasize local crash forensics and suspicious media/image handling rather than network indicators.

• KASAN: null-ptr-deref
• null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
• BUG: kernel NULL pointer dereference
• RIP: 0010:xlog_recover_reorder_trans
• xlog_recover_reorder_trans
• xlog_recover_commit_trans
• xlog_recover_process_data
• xlog_do_recovery_pass
• xlog_recover
• xfs_log_mount
• xfs_mountfs
• xfs_fs_fill_super
• XFS
• fs/xfs/xfs_log_recover.c
• path_mount
• __x64_sys_mount

What your security team should do

• Prioritize patching Linux systems that mount XFS filesystems from removable media, user-supplied images, VM disks, backup/snapshot workflows, storage appliances, CI pipelines, or forensic tooling.
• Disable or restrict automatic mounting of removable devices and disk images, especially on servers and privileged workstations.
• Ensure only trusted administrators and controlled automation can attach block devices, mount filesystems, or import VM/storage images.
• Run analysis of untrusted filesystem images in disposable, isolated virtual machines rather than on production hosts.
• Add monitoring for kernel oops/panic events and XFS recovery failures referencing xlog_recover_reorder_trans(), xlog_recover_commit_trans(), or NULL pointer dereferences during mount.
• Inventory systems using XFS and confirm their kernel packages receive security updates from the distribution or vendor.
• Treat repeated crashes during XFS mount or recovery as suspicious when they follow attachment of new media, imported disk images, or restored snapshots.