CVE-2026-64187: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-64187 Overview

CVE-2026-64187 is a NULL pointer dereference vulnerability in the Linux kernel's XFS filesystem log recovery code. The flaw resides in xlog_recover_reorder_trans() within fs/xfs/xfs_log_recover.c. When the first operation of a transaction is a bare transaction header, xlog_recover_add_to_trans() adds an item without any region, leaving it on r_itemq with ri_cnt == 0 and ri_buf == NULL. If the transaction later commits without adding any regions, the recovery reorder path dereferences the NULL ri_buf[0].iov_base, triggering a kernel fault. The issue was identified through an AI-assisted audit of the recovery parser.

Critical Impact
A crafted XFS log can trigger a kernel NULL pointer dereference during filesystem mount, causing a denial of service at boot or mount time.

Affected Products

Linux kernel (upstream) with XFS filesystem support enabled
Distributions shipping affected stable kernel branches prior to the referenced fix commits
Systems that mount untrusted or attacker-supplied XFS filesystem images

Discovery Timeline

2026-07-20 - CVE-2026-64187 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-64187

Vulnerability Analysis

The XFS log recovery subsystem replays journal entries during mount to bring the filesystem to a consistent state. Each transaction consists of a header followed by one or more regions describing changes. The parser in xlog_recover_add_to_trans() handles the case where a transaction begins with a bare header whose length equals sizeof(struct xfs_trans_header).

In that path, the parser allocates a recovery item and appends it to the r_itemq list without attaching any region buffer. The ri_cnt counter remains at zero and ri_buf remains NULL. This is valid intermediate state because the header may be split across multiple operation records, allowing later operations to attach regions.

The invariant breaks when the transaction commits with no regions ever added. The commit path calls xlog_recover_reorder_trans(), which invokes the ITEM_TYPE() macro. That macro dereferences item->ri_buf[0].iov_base, reading an unsigned short from a NULL pointer. KASAN reports a null-ptr-deref in the range [0x0000000000000000-0x0000000000000007].

Root Cause

The root cause is missing validation of the recovery item state before commit handlers dereference ri_buf. The parser accepts a committed transaction whose item list contains entries with zero regions, then downstream code assumes at least one region exists. The runtime commit path never emits such transactions, so triggering the fault requires a crafted log image.

Attack Vector

An attacker who can present a malicious XFS image to the kernel triggers the fault by mounting the filesystem. Common exposure paths include removable media auto-mount services, container image handling, and virtual machine disk images. The call chain runs from __x64_sys_mount through vfs_get_tree, xfs_fs_fill_super, xfs_mountfs, xfs_log_mount, xlog_recover, and finally xlog_recover_reorder_trans, where the NULL dereference occurs.

The vulnerability requires local access to submit the mount request, and mounting arbitrary filesystems typically requires privileged capabilities. The impact is a kernel oops or panic depending on system configuration, resulting in denial of service.

The fix rejects the committed item with no regions in xlog_recover_reorder_trans() before any commit handler reads ri_buf[0]. See the upstream patches for the exact validation logic: Kernel commit 2094dab1, Kernel commit cccbabeb, Kernel commit d50b1fd0, and Kernel commit d98f22d2.

Detection Methods for CVE-2026-64187

Indicators of Compromise

Kernel oops or KASAN report referencing xlog_recover_reorder_trans in fs/xfs/xfs_log_recover.c
Mount failures on XFS volumes accompanied by null-ptr-deref messages in dmesg
Unexpected mount attempts on attacker-controlled XFS images from removable media, container layers, or VM disks

Detection Strategies

Monitor kernel logs for panics or oopses whose stack traces include xlog_recover, xlog_do_recovery_pass, or xfs_log_mount
Audit mount syscall invocations that reference XFS filesystem types from untrusted sources or unprivileged workflows
Correlate mount events with subsequent kernel instability to identify potential exploitation attempts

Monitoring Recommendations

Enable kernel crash dump collection (kdump) to capture stack traces from suspected mount-time faults
Forward dmesg and journald kernel messages to a central log platform for pattern analysis
Track kernel package versions across the fleet to identify hosts running vulnerable XFS recovery code

How to Mitigate CVE-2026-64187

Immediate Actions Required

Update to a Linux kernel version that includes the referenced upstream fix commits for XFS log recovery
Restrict the ability to mount arbitrary filesystems by limiting CAP_SYS_ADMIN and disabling removable media auto-mount where feasible
Validate the provenance of container images and virtual machine disk images before mounting them on host systems

Patch Information

The fix has been merged into the stable kernel trees across the following commits: Kernel commit 2094dab1, Kernel commit cccbabeb, Kernel commit d50b1fd0, and Kernel commit d98f22d2. Apply the vendor kernel update from your distribution once the backport ships in stable channels.

Workarounds

Disable automatic mounting of removable media in udev or desktop environments to prevent untrusted XFS images from being parsed
Restrict unprivileged user namespaces where mount operations could be initiated without root privileges
Where possible, avoid mounting untrusted XFS images and prefer read-only inspection tooling in userspace instead

bash

# Disable removable media auto-mount in GNOME/GVFS as a defensive control
gsettings set org.gnome.desktop.media-handling automount false
gsettings set org.gnome.desktop.media-handling automount-open false

# Restrict unprivileged user namespaces (kernel sysctl)
sysctl -w kernel.unprivileged_userns_clone=0