Re: [PATCH] nilfs2: fix NULL i_assoc_inode dereference in nilfs_mdt_save_to_shadow_map

[Ryusuke Konishi]

On Tue, Mar 17, 2026 at 6:01 PM Deepanshu Kartikey wrote:
>
>
> The DAT inode's btree node cache (i_assoc_inode) is initialized lazily
> during btree operations. However, nilfs_mdt_save_to_shadow_map()
> assumes i_assoc_inode is already initialized when copying dirty pages
> to the shadow map during GC.
>
> If NILFS_IOCTL_CLEAN_SEGMENTS is called immediately after mount before
> any btree operation has occurred on the DAT inode, i_assoc_inode is
> NULL leading to a general protection fault.
>
> Fix this by calling nilfs_attach_btree_node_cache() on the DAT inode
> in nilfs_dat_read() at mount time, ensuring i_assoc_inode is always
> initialized before any GC operation can use it.
>
> Reported-by: syzbot+4b4093b1f24ad789bf37@xxxxxxxxxxxxxxxxxxxxxxxxx
> Closes: https://syzkaller.appspot.com/bug?extid=4b4093b1f24ad789bf37
> Tested-by: syzbot+4b4093b1f24ad789bf37@xxxxxxxxxxxxxxxxxxxxxxxxx
> Fixes: e897be17a441 ("nilfs2: fix lockdep warnings in page operations for btree nodes")
> Signed-off-by: Deepanshu Kartikey <Kartikey406@xxxxxxxxx>
> ---
>  fs/nilfs2/dat.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/fs/nilfs2/dat.c b/fs/nilfs2/dat.c
> index 674380837ab9..888dc1831c86 100644
> --- a/fs/nilfs2/dat.c
> +++ b/fs/nilfs2/dat.c
> @@ -524,6 +524,9 @@ int nilfs_dat_read(struct super_block *sb, size_t entry_size,
>         if (err)
>                 goto failed;
>
> +       err = nilfs_attach_btree_node_cache(dat);
> +       if (err)
> +               goto failed;
>         err = nilfs_read_inode_common(dat, raw_inode);
>         if (err)
>                 goto failed;
> --
> 2.43.0
>

As I've already answered in a discussion about another patch for the
same issue, I'd like to adopt Deepanshu's patch as the fix for this
issue, after doing a little more review (mainly for error cases) and
testing just to be sure.

This fix pre-allocates inodes for the b-tree node cache and is a
comprehensive stabilization technique that covers multiple potential
cases regarding non-existent b-tree node cache references.  Since DAT
usually starts using b-tree mapping very quickly, I believe this
approach is not overkill and is a practical solution.

Thanks,
Ryusuke Konishi