CVE-2024-47669 in Linux
Summary
by MITRE • 10/09/2024
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix state management in error path of log writing function
After commit a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write") was applied, the log writing function nilfs_segctor_do_construct() was able to issue I/O requests continuously even if user data blocks were split into multiple logs across segments, but two potential flaws were introduced in its error handling.
First, if nilfs_segctor_begin_construction() fails while creating the second or subsequent logs, the log writing function returns without calling nilfs_segctor_abort_construction(), so the writeback flag set on pages/folios will remain uncleared. This causes page cache operations to hang waiting for the writeback flag. For example, truncate_inode_pages_final(), which is called via nilfs_evict_inode() when an inode is evicted from memory, will hang.
Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does not, inodes with NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files" list, and their data and b-tree blocks may not be written to the device, corrupting the block mapping.
Fix these issues by uniformly calling nilfs_segctor_abort_construction() on failure of each step in the loop in nilfs_segctor_do_construct(), having it clean up logs and segment usages according to progress, and correcting the conditions for calling nilfs_redirty_inodes() to ensure that the NILFS_I_COLLECTED flag is cleared.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 03/21/2026
The vulnerability described in CVE-2024-47669 resides within the Linux kernel's nilfs2 file system implementation, specifically affecting the state management during error handling in the log writing function. This issue emerged following a particular commit that separated the wait function from the nilfs_segctor_write operation, which inadvertently introduced two critical flaws in the error path handling of the nilfs_segctor_do_construct() function. The nilfs2 file system operates as a log-structured file system that maintains data integrity through continuous logging mechanisms, making proper error handling essential for preventing data corruption and system instability. When user data blocks are split across multiple logs within segments, the system's ability to manage these operations correctly becomes paramount for maintaining file system consistency.
The first flaw manifests when nilfs_segctor_begin_construction() fails during the creation of subsequent logs, causing the function to return prematurely without invoking nilfs_segctor_abort_construction(). This omission leaves the writeback flag set on pages and folios in an uncleared state, creating a deadlock scenario where page cache operations become indefinitely blocked. The specific operational impact occurs when truncate_inode_pages_final() is invoked through nilfs_evict_inode() during inode eviction, resulting in system hangs that can severely impact file system responsiveness and overall system stability. This behavior represents a classic case of resource leak and state management failure that can cascade into broader system performance degradation.
The second vulnerability involves the improper handling of the NILFS_I_COLLECTED flag on normal inodes, which remains uncleared when errors occur during log writing operations. This flag serves as an indicator for inode collection status within the file system's dirty file management system, and its improper clearing leads to erroneous removal of inodes from the sc_dirty_files list during partial log writes. When checkpoint creation is not involved in the current log write, inodes marked with NILFS_I_COLLECTED are incorrectly removed from the dirty file tracking mechanism, potentially causing data and b-tree blocks to be omitted from device writes. This condition directly violates the fundamental principles of data consistency and can result in block mapping corruption that compromises file system integrity and data recovery capabilities.
The fix implemented addresses both identified flaws by ensuring uniform invocation of nilfs_segctor_abort_construction() whenever any step within the loop of nilfs_segctor_do_construct() fails. This approach provides comprehensive cleanup of logs and segment usages according to the actual progress made, preventing resource leaks and maintaining proper state consistency. Additionally, the correction of conditions for calling nilfs_redirty_inodes() ensures that the NILFS_I_COLLECTED flag is properly cleared, thereby maintaining the integrity of the dirty file tracking system. This remediation aligns with established security practices for proper error handling and resource management, addressing the underlying causes of both state management failures and potential data corruption scenarios. The solution effectively prevents the conditions that could lead to system hangs and data inconsistency issues while maintaining the core functionality of the nilfs2 file system's logging and writeback mechanisms.
This vulnerability demonstrates characteristics consistent with CWE-459 (Incomplete Cleanup) and CWE-755 (Improper Handling of Exceptional Conditions), representing a failure in proper resource management during error conditions. The operational impact can be classified under ATT&CK technique T1485 (Data Destruction) when considering potential data corruption scenarios, or T1490 (Inhibit System Recovery) when examining the system hang conditions that could prevent proper file system operation. The vulnerability underscores the critical importance of robust error handling in storage subsystems where improper state management can lead to both availability and data integrity issues, particularly in file systems that rely heavily on continuous logging mechanisms for data consistency.