linux-kernel - Re: [PATCH v2] f2fs: invalidate dentry cache on failed whiteout creation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8ad9e792-7b0a-4c93-8ad9-3f13e6f8614f@kernel.org>
Date: Tue, 28 Oct 2025 09:56:39 +0800
From: Chao Yu <chao@...nel.org>
To: Deepanshu Kartikey <kartikey406@...il.com>, jaegeuk@...nel.org
Cc: chao@...nel.org, linux-f2fs-devel@...ts.sourceforge.net,
 linux-kernel@...r.kernel.org,
 syzbot+632cf32276a9a564188d@...kaller.appspotmail.com, stable@...r.kernel.org
Subject: Re: [PATCH v2] f2fs: invalidate dentry cache on failed whiteout
 creation

On 10/27/25 21:06, Deepanshu Kartikey wrote:
> 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()
> 
> Fixes: 7e01e7ad746b ("f2fs: support RENAME_WHITEOUT")
> Reported-by: syzbot+632cf32276a9a564188d@...kaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=632cf32276a9a564188d
> Suggested-by: Chao Yu <chao@...nel.org>
> Link: https://lore.kernel.org/all/20251022233349.102728-1-kartikey406@gmail.com/ [v1]
> Cc: stable@...r.kernel.org
> Signed-off-by: Deepanshu Kartikey <kartikey406@...il.com>

Reviewed-by: Chao Yu <chao@...nel.org>

Thanks,