CVE-2026-64187 in Linuxinfo

Summary

by MITRE • 07/20/2026

In the Linux kernel, the following vulnerability has been resolved:

xfs: fail recovery on a committed log item with no regions

If the first op of a transaction is a bare transaction header (len == sizeof(struct xfs_trans_header)), xlog_recover_add_to_trans() adds an item but no region, leaving it on r_itemq with ri_cnt == 0 and ri_buf == NULL.

The header can be split across op records, so later ops may still add regions; the item is only invalid if the transaction commits with none. The runtime commit path never emits such a transaction, so this only happens on a crafted log. It came from an AI-assisted code audit of the recovery parser.

xlog_recover_reorder_trans() calls ITEM_TYPE() on the item, which reads *(unsigned short *)item->ri_buf[0].iov_base and faults on the NULL
ri_buf. Reject it there, before the commit handlers that also read ri_buf[0].

KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:xlog_recover_reorder_trans (fs/xfs/xfs_log_recover.c:1836) xlog_recover_commit_trans (fs/xfs/xfs_log_recover.c:2043) xlog_recover_process_data (fs/xfs/xfs_log_recover.c:2501) xlog_do_recovery_pass (fs/xfs/xfs_log_recover.c:3244) xlog_recover (fs/xfs/xfs_log_recover.c:3493) xfs_log_mount (fs/xfs/xfs_log.c:618) xfs_mountfs (fs/xfs/xfs_mount.c:1034) xfs_fs_fill_super (fs/xfs/xfs_super.c:1938) vfs_get_tree (fs/super.c:1695) path_mount (fs/namespace.c:4161) __x64_sys_mount (fs/namespace.c:4367)

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 07/20/2026

The vulnerability described represents a critical null pointer dereference in the Linux kernel's XFS file system recovery mechanism, specifically within the transaction recovery process. This issue arises during log recovery when processing malformed or crafted log entries that contain transactions with committed log items having no associated regions. The flaw manifests when the first operation of a transaction is a bare transaction header with a length equal to sizeof(struct xfs_trans_header), which results in an item being added to the recovery queue without any buffer regions. This condition creates an inconsistent state where ri_cnt remains zero and ri_buf is set to NULL, violating the expected data structure integrity required for proper recovery operations.

The technical execution path begins with xlog_recover_add_to_trans() function creating an invalid item state by adding a transaction header without subsequent region data allocation. Later during the recovery process, xlog_recover_reorder_trans() attempts to process this malformed item by calling ITEM_TYPE() macro which directly accesses (unsigned short )item->ri_buf[0].iov_base without validating that ri_buf is non-null. This direct memory access on a NULL pointer causes immediate system termination through kernel oops and KASAN null pointer dereference detection at the specified memory address range. The vulnerability is particularly dangerous because it occurs during the critical file system mount phase, where any crash can lead to complete system instability or denial of service.

This vulnerability directly maps to CWE-476 Null Pointer Dereference, a well-documented weakness that occurs when a null value is dereferenced as if it were a valid pointer. The issue also aligns with ATT&CK technique T1490 Network Denial of Service through resource exhaustion or system crash conditions, though in this case the impact results from a controlled memory access violation rather than resource exhaustion. The attack vector requires an adversary to craft a malicious XFS log file that triggers this specific recovery path, making it suitable for targeted attacks against systems where XFS is used as a primary file system and where log corruption or injection is possible. The severity is amplified because the crash occurs during mount time, which can prevent normal system operation and potentially enable privilege escalation if the attacker controls the log content.

The operational impact of this vulnerability extends beyond simple system crashes to encompass potential data integrity risks during recovery operations. When a system attempts to mount an XFS file system with corrupted logs containing these malformed transactions, the kernel will immediately crash upon encountering the invalid item state. This behavior effectively prevents normal file system access and can result in complete system downtime until the problematic log is manually removed or repaired. The recovery process itself becomes unreliable as it cannot properly handle malformed transaction entries that should be rejected during early validation phases rather than allowed to propagate through the system. Organizations using XFS file systems, particularly those with automated mount procedures or systems where log corruption might occur, face significant operational risks from this vulnerability without proper mitigation.

Mitigation strategies for this vulnerability require both immediate kernel patching and operational hardening measures. The primary fix involves adding validation checks in xlog_recover_reorder_trans() before attempting to access ri_buf[0] to ensure that the buffer pointer is non-null before proceeding with ITEM_TYPE() macro evaluation. Additionally, system administrators should implement robust log monitoring and integrity verification procedures for XFS file systems, particularly those used in environments where external or untrusted sources might influence log content. Regular backup and recovery testing should include validation of log consistency to prevent propagation of corrupted transaction states. Organizations should also consider implementing intrusion detection systems that monitor for suspicious file system mount operations or memory access patterns that might indicate exploitation attempts. The fix should be applied across all systems running affected kernel versions, with particular attention to enterprise environments where automated recovery procedures might be triggered by unexpected log corruption events.

Responsible

Linux

Reservation

07/19/2026

Disclosure

07/20/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

low

Sources

Might our Artificial Intelligence support you?

Check our Alexa App!