CVE-2026-89601 in Linux
Summary
by MITRE • 09/12/2026
In the Linux kernel, the following vulnerability has been resolved:
ext2: Fix lost inode updates for IS_SYNC inodes
ext2_setsize() and ext2_xattr_set2() had a construct like:
if (IS_SYNC(inode)) {
sync_inode_metadata(inode, 1); } else {
mark_inode_dirty(inode); }
which leads to lost inode updates for IS_SYNC inodes because sync_inode_metadata() does anything only if the inode is already dirty and hence inode updates may be simply lost. Fix the problem by unconditionally marking the inode dirty and *then* call sync_inode_metadata().
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/12/2026
The Linux kernel's ext2 filesystem driver contains a logic flaw in how it handles metadata synchronization for specific types of inodes, specifically those marked with the IS_SYNC flag. This vulnerability manifests within two primary functions: ext2_setsize(), which manages changes to file size, and ext2_xattr_set2(), which handles extended attribute modifications. The core issue stems from an incorrect conditional check that attempts to optimize synchronous writes by bypassing certain steps under specific conditions. When a filesystem operation targets an inode designated as IS_SYNC, the code invokes sync_inode_metadata() directly without first ensuring the inode is marked as dirty in the kernel's internal tracking structures.
The technical root cause lies in the behavior of the sync_inode_metadata function within the VFS layer. This function is designed to flush metadata changes that are already queued for writing to disk. It does not independently trigger a state change on the inode itself; it merely acts upon existing dirty flags. Consequently, if an inode has not been previously marked as dirty by the calling routine, sync_inode_metadata() effectively becomes a no-op because there is nothing in its queue to synchronize. This creates a race condition where updates to critical metadata such as file size or extended attributes are silently discarded rather than being persisted to storage media. The original code structure assumed that the act of reaching this branch implied readiness for synchronization, failing to account for the prerequisite state required by the underlying VFS mechanisms.
The operational impact of this vulnerability is severe data integrity risk. For applications relying on synchronous I/O semantics, such as databases or transactional logging systems, file size updates and extended attribute changes may fail to persist after a system crash or power loss. This leads to silent corruption where the filesystem reports success for an operation that was never actually committed to disk. Over time, this can result in inconsistent file states, truncated files, or lost metadata, compromising the reliability of storage systems running ext2 with synchronous mount options or applications explicitly requesting sync behavior. The lack of explicit error reporting means administrators and developers may remain unaware that their data protection mechanisms are not functioning as intended until a catastrophic failure occurs.
To mitigate this vulnerability, it is essential to apply kernel patches that correct the ordering of operations within these functions. The fix involves unconditionally marking the inode as dirty using mark_inode_dirty() before invoking sync_inode_metadata(). This ensures that the VFS layer recognizes the pending changes and includes them in the subsequent synchronization cycle. System administrators should ensure their kernels are updated with this specific patch, particularly if they utilize ext2 for critical workloads requiring strong durability guarantees. Additionally, verifying filesystem consistency through regular fsck operations is recommended to detect any potential inconsistencies arising from prior occurrences of this bug.
From a classification perspective, this vulnerability aligns with CWE-367, which describes Time-of-check Time-of-use (TOCTOU) race conditions, specifically involving incorrect state management leading to lost updates. It also relates to CWE-829, where the inclusion of unnecessary functionality or flawed logic leads to security-relevant failures in data integrity. In terms of attack vectors and defensive mapping, this issue falls under MITRE ATT&CK technique T1485, which covers Data Destruction via filesystem manipulation. While not directly exploitable by an external attacker for remote code execution, it represents a significant reliability flaw that can be leveraged to cause denial of service through data loss or corruption in environments where synchronous I/O is critical for security and compliance requirements.