CVE-2026-80529 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
xfs: don't swallow dquot recovery verification errors
xlog_recover_dquot_commit_pass2() validates the recovered dquot with xfs_dqblk_verify() and, on failure, sets error = -EFSCORRUPTED and jumps to out_release. But out_release unconditionally returns 0, so the corruption error is discarded: the caller xlog_recover_items_pass2() sees success, log recovery proceeds as if the dquot were valid, and the corrupt quota buffer can be written back to disk.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The Linux kernel's XFS filesystem implementation contains a critical logic flaw within its journaling subsystem that allows corrupted disk quotas to persist on storage media without triggering appropriate error handling or recovery procedures. This vulnerability resides specifically in the function xlog_recover_dquot_commit_pass2, which is responsible for validating recovered dquot structures during the second pass of log recovery operations. The core technical issue stems from an incorrect control flow path where a detected corruption condition fails to propagate its associated error code back to the calling context. When the validation routine xfs_dqblk_verify detects inconsistencies in the quota block data, it correctly assigns the -EFSCORRUPTED error code and attempts to exit via the out_release label. However, this specific exit path unconditionally returns zero, effectively masking the corruption detection from higher-level recovery mechanisms.
This design flaw results in a silent failure scenario where the filesystem journaling system proceeds under the false assumption that the quota data is valid. Consequently, the corrupted dquot buffer may be written back to disk during subsequent operations, potentially leading to further filesystem instability or incorrect accounting of resource usage by users and processes. The impact extends beyond simple data integrity issues; it can lead to situations where quotas are effectively bypassed because the kernel continues to operate with invalid quota limits derived from the corrupt structures. This undermines the reliability of resource management mechanisms that depend on accurate dquot information, potentially allowing unauthorized or excessive consumption of disk space by specific users or groups without triggering expected enforcement actions.
From a security and standards perspective, this vulnerability aligns closely with CWE-253, which describes incorrect check for condition errors where software does not properly verify the outcome of an operation before proceeding. The failure to propagate error codes constitutes a logic error that prevents proper exception handling within the kernel's recovery subsystem. In terms of attack surface analysis, while this is primarily a stability and integrity issue rather than a direct remote code execution vector, it falls under categories related to improper input validation and state management errors found in ATT&CK techniques involving persistence or privilege escalation if an attacker can induce specific corruption patterns through crafted filesystem operations. The lack of proper error propagation allows the system to maintain an inconsistent internal state that deviates from expected operational norms defined by POSIX standards for quota enforcement.
Mitigation strategies must focus on correcting the control flow within the xlog_recover_dquot_commit_pass2 function to ensure that non-zero error codes are returned when validation fails. Developers should modify the out_release path or introduce a dedicated exit label that properly returns the -EFSCORRUPTED status code to xlog_recover_items_pass2. This ensures that the caller recognizes the recovery failure and can take appropriate action, such as aborting the mount operation with an error message or initiating more aggressive repair procedures rather than proceeding with potentially dangerous data. Additionally, implementing stricter verification checks during initial log replay phases could help detect these anomalies earlier in the boot process before they are committed to persistent storage. System administrators should monitor kernel logs for EFSCORRUPTED errors and consider running xfs_repair utilities if such corruption is suspected to prevent long-term filesystem degradation caused by silently accepted invalid quota structures.