lkml.org 
[lkml]   [2024]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [syzbot] [ext4?] KASAN: slab-use-after-free Read in fsnotify
Date
On Sat, 13 Apr 2024 12:32:32 +0300 Amir Goldstein
> On Sat, Apr 13, 2024 at 11:45=E2=80=AFAM Hillf Danton <hdanton@sina.com> wrote:
> >
> > If you composed fix based on SB_ACTIVE that is cleared in
> > generic_shutdown_super() with &sb->s_umount held for write,
> > I wonder what simpler serialization than srcu you could
> > find/create in fsnotify.
>
> As far as I can tell there is no need for serialisation.
>
> The problem is that fsnotify_sb_error() can be called from the
> context of ->put_super() call from generic_shutdown_super().
>
> It's true that in the repro the thread calling fsnotify_sb_error()
> in the worker thread running quota deferred work from put_super()
> but I think there are sufficient barriers for this worker thread to
> observer the cleared SB_ACTIVE flag.
>
do_exit quota_release_workfn
--- ---
cleanup_mnt() ext4_release_dquot()
__super_lock_excl(s); __ext4_error()
deactivate_locked_super(s); fsnotify_sb_error()
ext4_kill_sb()
kill_block_super()
generic_shutdown_super()
if (!(sb->s_flags & SB_ACTIVE))
return;
sb->s_flags &= ~SB_ACTIVE;
fsnotify_sb_delete()
fsnotify()

Because of no sync like taking &sb->s_umount in the worker context,
checking SB_ACTIVE added in your fix is unable to close the race.

> Anyway, according to syzbot, repro does not trigger the UAF
> with my last fix.
>
Note: testing is done by a robot and is best-effort only.

\
 
 \ /
  Last update: 2024-05-27 16:39    [W:0.054 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site