Received-SPF: pass (google.com: domain of linux-kernel+bounces-143598-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 12 Apr 2024 23:42:19 -0700
In-Reply-To: <00000000000042c9190615cdb315@google.com>
Message-ID: <00000000000095bb400615f4b0ed@google.com>
Subject: Re: [syzbot] Re: [syzbot] [ext4?] KASAN: slab-use-after-free Read in fsnotify
From: syzbot <syzbot+5e3f9b2a67b45f16d4e6@syzkaller.appspotmail.com>
To: linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.

***

Subject: Re: [syzbot] [ext4?] KASAN: slab-use-after-free Read in fsnotify
Author: amir73il@gmail.com

On Sat, Apr 13, 2024 at 4:41=E2=80=AFAM Hillf Danton <hdanton@sina.com> wro=
te:
>
> On Thu, 11 Apr 2024 01:11:20 -0700
> > syzbot found the following issue on:
> >
> > HEAD commit:    6ebf211bb11d Add linux-next specific files for 20240410
> > git tree:       linux-next
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=3D1621af9d180=
000
>
> #syz test https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next=
git  6ebf211bb11d
>
> --- x/fs/notify/fsnotify.c
> +++ y/fs/notify/fsnotify.c
> @@ -101,8 +101,8 @@ void fsnotify_sb_delete(struct super_blo
>         wait_var_event(fsnotify_sb_watched_objects(sb),
>                        !atomic_long_read(fsnotify_sb_watched_objects(sb))=
);
>         WARN_ON(fsnotify_sb_has_priority_watchers(sb, FSNOTIFY_PRIO_CONTE=
NT));
> -       WARN_ON(fsnotify_sb_has_priority_watchers(sb,
> -                                                 FSNOTIFY_PRIO_PRE_CONTE=
NT));
> +       WARN_ON(fsnotify_sb_has_priority_watchers(sb, FSNOTIFY_PRIO_PRE_C=
ONTENT));
> +       synchronize_srcu(&fsnotify_mark_srcu);
>         kfree(sbinfo);
>  }
>
> @@ -499,7 +499,7 @@ int fsnotify(__u32 mask, const void *dat
>  {
>         const struct path *path =3D fsnotify_data_path(data, data_type);
>         struct super_block *sb =3D fsnotify_data_sb(data, data_type);
> -       struct fsnotify_sb_info *sbinfo =3D fsnotify_sb_info(sb);
> +       struct fsnotify_sb_info *sbinfo;
>         struct fsnotify_iter_info iter_info =3D {};
>         struct mount *mnt =3D NULL;
>         struct inode *inode2 =3D NULL;
> @@ -529,6 +529,8 @@ int fsnotify(__u32 mask, const void *dat
>                 inode2_type =3D FSNOTIFY_ITER_TYPE_PARENT;
>         }
>
> +       iter_info.srcu_idx =3D srcu_read_lock(&fsnotify_mark_srcu);
> +       sbinfo =3D fsnotify_sb_info(sb);
>         /*
>          * Optimization: srcu_read_lock() has a memory barrier which can
>          * be expensive.  It protects walking the *_fsnotify_marks lists.


See comment above. This kills the optimization.
It is not worth letting all the fsnotify hooks suffer the consequence
for the edge case of calling fsnotify hook during fs shutdown.

Also, fsnotify_sb_info(sb) in fsnotify_sb_has_priority_watchers()
is also not protected and using srcu_read_lock() there completely
nullifies the purpose of fsnotify_sb_info.

Here is a simplified fix for fsnotify_sb_error() rebased on the
pending mm fixes for this syzbot boot failure:

#syz test: https://github.com/amir73il/linux fsnotify-fixes

Jan,

I think that all the functions called from fs shutdown context
should observe that SB_ACTIVE is cleared but wasn't sure?

Thanks,
Amir.