CVE-2025-71069

Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
13/01/2026
Last modified:
13/01/2026

Description

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: invalidate dentry cache on failed whiteout creation<br /> <br /> F2FS can mount filesystems with corrupted directory depth values that<br /> get runtime-clamped to MAX_DIR_HASH_DEPTH. When RENAME_WHITEOUT<br /> operations are performed on such directories, f2fs_rename performs<br /> directory modifications (updating target entry and deleting source<br /> entry) before attempting to add the whiteout entry via f2fs_add_link.<br /> <br /> If f2fs_add_link fails due to the corrupted directory structure, the<br /> function returns an error to VFS, but the partial directory<br /> modifications have already been committed to disk. VFS assumes the<br /> entire rename operation failed and does not update the dentry cache,<br /> leaving stale mappings.<br /> <br /> In the error path, VFS does not call d_move() to update the dentry<br /> cache. This results in new_dentry still pointing to the old inode<br /> (new_inode) which has already had its i_nlink decremented to zero.<br /> The stale cache causes subsequent operations to incorrectly reference<br /> the freed inode.<br /> <br /> This causes subsequent operations to use cached dentry information that<br /> no longer matches the on-disk state. When a second rename targets the<br /> same entry, VFS attempts to decrement i_nlink on the stale inode, which<br /> may already have i_nlink=0, triggering a WARNING in drop_nlink().<br /> <br /> Example sequence:<br /> 1. First rename (RENAME_WHITEOUT): file2 → file1<br /> - f2fs updates file1 entry on disk (points to inode 8)<br /> - f2fs deletes file2 entry on disk<br /> - f2fs_add_link(whiteout) fails (corrupted directory)<br /> - Returns error to VFS<br /> - VFS does not call d_move() due to error<br /> - VFS cache still has: file1 → inode 7 (stale!)<br /> - inode 7 has i_nlink=0 (already decremented)<br /> <br /> 2. Second rename: file3 → file1<br /> - VFS uses stale cache: file1 → inode 7<br /> - Tries to drop_nlink on inode 7 (i_nlink already 0)<br /> - WARNING in drop_nlink()<br /> <br /> Fix this by explicitly invalidating old_dentry and new_dentry when<br /> f2fs_add_link fails during whiteout creation. This forces VFS to<br /> refresh from disk on subsequent operations, ensuring cache consistency<br /> even when the rename partially succeeds.<br /> <br /> Reproducer:<br /> 1. Mount F2FS image with corrupted i_current_depth<br /> 2. renameat2(file2, file1, RENAME_WHITEOUT)<br /> 3. renameat2(file3, file1, 0)<br /> 4. System triggers WARNING in drop_nlink()

Impact