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
References to Advisories, Solutions, and Tools
- https://git.kernel.org/stable/c/0dde30753c1e8648665dbe069d814e540ce2fd37
- https://git.kernel.org/stable/c/3d65e27e57aaa9d66709fda4cbfb62a87c04a3f5
- https://git.kernel.org/stable/c/64587ab4d1f16fc94f70e04fa87b2e3f69f8a7bb
- https://git.kernel.org/stable/c/c89845fae250efdd59c1d4ec60e9e1c652cee4b6
- https://git.kernel.org/stable/c/d33f89b34aa313f50f9a512d58dd288999f246b0



