On Tue, 29 Mar 2022 at 13:50, Ritesh Harjani <ritesh.list@xxxxxxxxx> wrote: > > On 22/03/25 07:18AM, Dmitry Vyukov wrote: > > On Wed, 23 Mar 2022 at 16:07, syzbot > > <syzbot+4cb1e27475bf90a9b926@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > syzbot suspects this issue was fixed by commit: > > > > > > commit 6e47a3cc68fc525428297a00524833361ebbb0e9 > > > Author: Lukas Czerner <lczerner@xxxxxxxxxx> > > > 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
