All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: Ritesh Harjani <ritesh.list@gmail.com>
Cc: syzbot <syzbot+4cb1e27475bf90a9b926@syzkaller.appspotmail.com>,
	adilger.kernel@dilger.ca, cmaiolino@redhat.com,
	lczerner@redhat.com, linux-ext4@vger.kernel.org,
	linux-kernel@vger.kernel.org, sjc@chobot.com,
	syzkaller-bugs@googlegroups.com, tytso@mit.edu,
	wanjiabing@vivo.com
Subject: Re: [syzbot] KASAN: use-after-free Read in ext4_xattr_set_entry (4)
Date: Tue, 29 Mar 2022 14:01:22 +0200	[thread overview]
Message-ID: <CACT4Y+ZhCWZhrzt9bW-Q=munq9RC+eow8zCpJU1fzFiEGQa+6w@mail.gmail.com> (raw)
In-Reply-To: <20220329115011.5fyhukqlfvvzojbg@riteshh-domain>

On Tue, 29 Mar 2022 at 13:50, Ritesh Harjani <ritesh.list@gmail.com> wrote:
>
> On 22/03/25 07:18AM, Dmitry Vyukov wrote:
> > On Wed, 23 Mar 2022 at 16:07, syzbot
> > <syzbot+4cb1e27475bf90a9b926@syzkaller.appspotmail.com> wrote:
> > >
> > > syzbot suspects this issue was fixed by commit:
> > >
> > > commit 6e47a3cc68fc525428297a00524833361ebbb0e9
> > > Author: Lukas Czerner <lczerner@redhat.com>
> > > Date:   Wed Oct 27 14:18:52 2021 +0000
> > >
> > >     ext4: get rid of super block and sbi from handle_mount_ops()
> > >
> > > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=100bc10b700000
> > > start commit:   f8ad8187c3b5 fs/pipe: allow sendfile() to pipe again
> > > git tree:       upstream
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=96b123631a6700e9
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=4cb1e27475bf90a9b926
> > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11131f94d00000
> > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15c3761b500000
> > >
> > > If the result looks correct, please mark the issue as fixed by replying with:
> > >
> > > #syz fix: ext4: get rid of super block and sbi from handle_mount_ops()
> > >
> > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> >
> > Looks reasonable:
> >
> > #syz fix: ext4: get rid of super block and sbi from handle_mount_ops()
>
> Sorry, I might have missed some discussion maybe.
> But why do we think that this patch could fix the reported bug?
> Because I see this patch from Lukas is a part of "ext4: new mount API
> conversion" patch series. This I guess has nothing to do with the reported call
> stack, no?
>
> Or am I missing anything?

Hi Ritesh,

It looked reasonable because the identified patch is in ext4 and the
bug is also in ext4 + the bisection log looked reasonable + there were
no other suggestions/corrections. In such a case it's better to close
the bug with at least some reasonable fix, then let it pile to
hundreds of other unclosed bugs and prevent reporting of new bugs.



> BUG: KASAN: use-after-free in ext4_xattr_set_entry+0x3151/0x3780 fs/ext4/xattr.c:1586
> Read of size 4 at addr ffff888030c00004 by task syz-executor392/11280
>
> CPU: 0 PID: 11280 Comm: syz-executor392 Not tainted 5.11.0-rc5-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:79 [inline]
>  dump_stack+0x107/0x163 lib/dump_stack.c:120
>  print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:230
>  __kasan_report mm/kasan/report.c:396 [inline]
>  kasan_report.cold+0x79/0xd5 mm/kasan/report.c:413
>  ext4_xattr_set_entry+0x3151/0x3780 fs/ext4/xattr.c:1586
>  ext4_xattr_ibody_set+0x78/0x2b0 fs/ext4/xattr.c:2224
>  ext4_xattr_set_handle+0x8f4/0x13e0 fs/ext4/xattr.c:2380
>  ext4_xattr_set+0x13a/0x340 fs/ext4/xattr.c:2493
>  __vfs_setxattr+0x10e/0x170 fs/xattr.c:177
>  __vfs_setxattr_noperm+0x11a/0x4c0 fs/xattr.c:208
>  __vfs_setxattr_locked+0x1bf/0x250 fs/xattr.c:266
>  vfs_setxattr+0x135/0x320 fs/xattr.c:291
>  setxattr+0x1ff/0x290 fs/xattr.c:553
>  path_setxattr+0x170/0x190 fs/xattr.c:572
>  __do_sys_setxattr fs/xattr.c:587 [inline]
>  __se_sys_setxattr fs/xattr.c:583 [inline]
>  __x64_sys_setxattr+0xc0/0x160 fs/xattr.c:583
>  do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
>
>
> -ritesh

      reply	other threads:[~2022-03-29 12:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-30 11:05 KASAN: use-after-free Read in ext4_xattr_set_entry (4) syzbot
2022-03-23 15:07 ` [syzbot] " syzbot
2022-03-25  6:18   ` Dmitry Vyukov
2022-03-29 11:50     ` Ritesh Harjani
2022-03-29 12:01       ` Dmitry Vyukov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACT4Y+ZhCWZhrzt9bW-Q=munq9RC+eow8zCpJU1fzFiEGQa+6w@mail.gmail.com' \
    --to=dvyukov@google.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=cmaiolino@redhat.com \
    --cc=lczerner@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ritesh.list@gmail.com \
    --cc=sjc@chobot.com \
    --cc=syzbot+4cb1e27475bf90a9b926@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=tytso@mit.edu \
    --cc=wanjiabing@vivo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.