fuse_dentry_revalidate() may be called with a dentry that didn't had
->d_time initialised.  The issue was found with KMSAN, where lookup_open()
calls __d_alloc(), followed by d_revalidate(), as shown below:

=====================================================
BUG: KMSAN: uninit-value in fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394
 fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394
 d_revalidate fs/namei.c:1030 [inline]
 lookup_open fs/namei.c:4405 [inline]
 open_last_lookups fs/namei.c:4583 [inline]
 path_openat+0x1614/0x64c0 fs/namei.c:4827
 do_file_open+0x2aa/0x680 fs/namei.c:4859
[...]

Uninit was created at:
 slab_post_alloc_hook mm/slub.c:4466 [inline]
 slab_alloc_node mm/slub.c:4788 [inline]
 kmem_cache_alloc_lru_noprof+0x382/0x1280 mm/slub.c:4807
 __d_alloc+0x55/0xa00 fs/dcache.c:1740
 d_alloc_parallel+0x99/0x2740 fs/dcache.c:2604
 lookup_open fs/namei.c:4398 [inline]
 open_last_lookups fs/namei.c:4583 [inline]
 path_openat+0x135f/0x64c0 fs/namei.c:4827
 do_file_open+0x2aa/0x680 fs/namei.c:4859
[...]
=====================================================

Reported-by: syzbot+fdebb2dc960aa56c600a@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/69917e0d.050a0220.340abe.02e2.GAE@google.com
Fixes: 2396356a945b ("fuse: add more control over cache invalidation behaviour")
Signed-off-by: Luis Henriques <luis@igalia.com>
---
 fs/fuse/dir.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
index f25ee47822ad..66f0113ddfaf 100644
--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -481,6 +481,11 @@ static int fuse_dentry_init(struct dentry *dentry)
 	fd->dentry = dentry;
 	RB_CLEAR_NODE(&fd->node);
 	dentry->d_fsdata = fd;
+	/*
+	 * Initialising d_time (epoch) to '0' ensures the dentry is invalid
+	 * if compared to fc->epoch, which is initialized to '1'.
+	 */
+	dentry->d_time = 0;
 
 	return 0;
 }

On Mon, 16 Feb 2026 at 15:48, Luis Henriques <luis@igalia.com> wrote:
>
> fuse_dentry_revalidate() may be called with a dentry that didn't had
> ->d_time initialised.  The issue was found with KMSAN, where lookup_open()
> calls __d_alloc(), followed by d_revalidate(), as shown below:
>
> =====================================================
> BUG: KMSAN: uninit-value in fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394
>  fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394
>  d_revalidate fs/namei.c:1030 [inline]
>  lookup_open fs/namei.c:4405 [inline]
>  open_last_lookups fs/namei.c:4583 [inline]
>  path_openat+0x1614/0x64c0 fs/namei.c:4827
>  do_file_open+0x2aa/0x680 fs/namei.c:4859
> [...]
>
> Uninit was created at:
>  slab_post_alloc_hook mm/slub.c:4466 [inline]
>  slab_alloc_node mm/slub.c:4788 [inline]
>  kmem_cache_alloc_lru_noprof+0x382/0x1280 mm/slub.c:4807
>  __d_alloc+0x55/0xa00 fs/dcache.c:1740
>  d_alloc_parallel+0x99/0x2740 fs/dcache.c:2604
>  lookup_open fs/namei.c:4398 [inline]
>  open_last_lookups fs/namei.c:4583 [inline]
>  path_openat+0x135f/0x64c0 fs/namei.c:4827
>  do_file_open+0x2aa/0x680 fs/namei.c:4859
> [...]
> =====================================================
>
> Reported-by: syzbot+fdebb2dc960aa56c600a@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/69917e0d.050a0220.340abe.02e2.GAE@google.com
> Fixes: 2396356a945b ("fuse: add more control over cache invalidation behaviour")
> Signed-off-by: Luis Henriques <luis@igalia.com>

Applied, thanks.

Miklos