CVE-2025-71069 in Linux
Summary
by MITRE • 01/13/2026
In the Linux kernel, the following vulnerability has been resolved:
f2fs: invalidate dentry cache on failed whiteout creation
F2FS can mount filesystems with corrupted directory depth values that get runtime-clamped to MAX_DIR_HASH_DEPTH. When RENAME_WHITEOUT operations are performed on such directories, f2fs_rename performs directory modifications (updating target entry and deleting source entry) before attempting to add the whiteout entry via f2fs_add_link.
If f2fs_add_link fails due to the corrupted directory structure, the function returns an error to VFS, but the partial directory modifications have already been committed to disk. VFS assumes the entire rename operation failed and does not update the dentry cache, leaving stale mappings.
In the error path, VFS does not call d_move() to update the dentry cache. This results in new_dentry still pointing to the old inode (new_inode) which has already had its i_nlink decremented to zero. The stale cache causes subsequent operations to incorrectly reference the freed inode.
This causes subsequent operations to use cached dentry information that no longer matches the on-disk state. When a second rename targets the same entry, VFS attempts to decrement i_nlink on the stale inode, which may already have i_nlink=0, triggering a WARNING in drop_nlink().
Example sequence: 1. First rename (RENAME_WHITEOUT): file2 → file1 - f2fs updates file1 entry on disk (points to inode 8) - f2fs deletes file2 entry on disk - f2fs_add_link(whiteout) fails (corrupted directory) - Returns error to VFS - VFS does not call d_move() due to error - VFS cache still has: file1 → inode 7 (stale!) - inode 7 has i_nlink=0 (already decremented)
2. Second rename: file3 → file1 - VFS uses stale cache: file1 → inode 7 - Tries to drop_nlink on inode 7 (i_nlink already 0) - WARNING in drop_nlink()
Fix this by explicitly invalidating old_dentry and new_dentry when f2fs_add_link fails during whiteout creation. This forces VFS to refresh from disk on subsequent operations, ensuring cache consistency even when the rename partially succeeds.
Reproducer: 1. Mount F2FS image with corrupted i_current_depth 2. renameat2(file2, file1, RENAME_WHITEOUT) 3. renameat2(file3, file1, 0) 4. System triggers WARNING in drop_nlink()
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/16/2026
The vulnerability described in CVE-2025-71069 affects the F2FS (Flash-Friendly File System) implementation within the Linux kernel, specifically in how it handles rename operations with whiteout flags when directory structures are corrupted. This flaw stems from an improper handling of dentry cache updates during partial transaction failures, leading to inconsistent filesystem state and potential system warnings. The core issue manifests when the kernel attempts to perform a rename operation with the RENAME_WHITEOUT flag on directories whose depth values have been corrupted and clamped to the maximum allowed value. During such operations, the filesystem modifies directory entries before attempting to create a whiteout entry through the f2fs_add_link function. When this final step fails due to structural corruption, the preceding directory modifications are already committed to disk, but the Virtual File System (VFS) layer fails to invalidate the dentry cache properly, resulting in stale mappings that persist in memory.
The technical execution of this vulnerability involves a sequence where the kernel first updates the target directory entry to point to a new inode while deleting the source entry, but fails to complete the whiteout creation step. This partial success leaves the directory structure in an inconsistent state where the on-disk metadata no longer aligns with the cached dentry information. According to CWE-691, this represents an insufficient control flow management issue where the error handling path does not properly account for partial state changes, leading to a dangerous inconsistency. The VFS layer, which manages file system metadata and dentry caching, assumes the entire operation failed and does not invoke the d_move() function to update the cache, leaving stale dentry references that point to freed inodes. This behavior directly violates the expected transactional semantics of file system operations, where either the entire operation succeeds or fails completely without leaving intermediate states.
The operational impact of this vulnerability extends beyond simple warnings to potentially compromise filesystem integrity and system stability. When subsequent operations target the same directory entry, the stale dentry cache causes VFS to reference inodes that have already been freed, leading to the drop_nlink() function triggering warnings when it attempts to decrement a link count that has already reached zero. This situation can escalate into more serious issues such as data corruption, system crashes, or denial of service conditions, particularly in environments where frequent rename operations are performed on potentially corrupted filesystems. The vulnerability is particularly concerning in embedded systems or storage environments where F2FS is commonly used, as it can cause cascading failures in applications that depend on consistent file system behavior. This flaw also aligns with ATT&CK technique T1490, which covers data destruction, as the inconsistent state can lead to data loss or corruption when applications attempt to access freed inodes. The issue becomes more pronounced in scenarios involving concurrent operations or when filesystem corruption is present due to power failures or hardware issues during write operations.
Mitigation of this vulnerability requires explicit invalidation of dentry cache entries when the f2fs_add_link function fails during whiteout creation, ensuring that subsequent operations will refresh their cache from the on-disk state rather than relying on stale mappings. The fix implements proper error handling by ensuring that when the whiteout creation step fails, the VFS layer invalidates both the old and new dentry references, forcing a refresh from disk on subsequent access attempts. This approach aligns with best practices for transactional file system implementations where partial operations must not leave the system in an inconsistent state. System administrators should prioritize applying kernel updates that include this fix, particularly in production environments where F2FS is actively used. Additionally, monitoring for WARNING messages related to drop_nlink() can serve as an early indicator of this vulnerability's exploitation, though such monitoring should be combined with regular filesystem checks to identify and address underlying corruption issues. The solution demonstrates the importance of maintaining cache consistency in distributed systems and reinforces the principle that error paths must properly account for all state changes, even those that have already been committed to persistent storage.