CVE-2026-97546 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
xfs: don't spin forever on zero-length dirents when salvaging them
LOLLM noticed that xrep_dir_recover_data can spin forever if it encounters an unused dirent that claims to have length zero. Fix that, and prevent the same thing from happening with a zero-length entry.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The XFS filesystem implementation within the Linux kernel contains a logic flaw in its directory recovery mechanism that leads to infinite CPU consumption under specific conditions. This vulnerability is located in the xrep_dir_recover_data function, which is part of the salvage process used when repairing corrupted or inconsistent directory structures on disk. The core issue arises when the recovery algorithm encounters an unused directory entry (dirent) that claims to have a length of zero. In normal operation, XFS expects directory entries to contain valid data and lengths consistent with their content. However, due to filesystem corruption, maliciously crafted images, or edge cases in journal replay, it is possible for metadata on disk to become inconsistent. When the recovery code processes such an anomalous entry, it fails to properly advance its internal pointers or break out of the processing loop because a zero-length claim does not provide enough information to determine where the next valid entry begins. Consequently, the algorithm enters an infinite spin loop, consuming 100 percent of a CPU core indefinitely and effectively causing a denial of service for any process relying on that filesystem's responsiveness.
From a technical perspective, this flaw represents a failure in input validation and boundary checking during metadata recovery operations. The code assumes that all directory entries encountered during salvage will have non-zero lengths or valid structures that allow the iterator to move forward through the block. By not explicitly handling the case where an entry reports zero length, the kernel lacks a safeguard against malformed data. This is particularly dangerous because filesystem repair tools are often run by system administrators on potentially compromised or severely degraded systems. If an attacker can manipulate disk images or exploit other vulnerabilities to write corrupted directory entries, they could trigger this infinite loop remotely if the affected volume is mounted and accessed during recovery operations. The lack of a timeout mechanism or length validation allows local denial-of-service conditions that are difficult to mitigate without restarting the system or killing the hung process, which may not be possible if critical kernel threads are involved in the hang.
This vulnerability aligns with CWE-835, Loop Without Ending Condition, as the code enters an iterative loop that lacks a proper termination condition for certain inputs. It also relates to CWE-20, Improper Input Validation, because the recovery routine fails to validate the integrity and plausibility of the directory entry length before proceeding. In terms of attack vectors, this could be leveraged in scenarios involving physical access or compromised storage media where an attacker injects malformed XFS metadata. While primarily a local denial-of-service issue, it impacts system availability and stability, which are critical components of security posture. The ATT&CK framework categorizes such behavior under resource hijacking techniques that aim to degrade service availability by exhausting computational resources through inefficient code execution paths triggered by specific data patterns.
To mitigate this risk, the Linux kernel maintainers have implemented a fix that explicitly checks for zero-length directory entries during the salvage process and handles them appropriately rather than allowing the loop to continue indefinitely. System administrators should ensure their kernels are updated with patches addressing this XFS directory recovery flaw. Additionally, regular filesystem consistency checks using tools like xfs_repair can help identify and correct underlying metadata corruption before it triggers such edge cases in production environments. Monitoring for high CPU usage on systems performing filesystem repairs or mounts of potentially untrusted storage media is also recommended as a defensive measure against potential exploitation attempts targeting this specific logic error.