Re: syzkaller@googlegroups.com

Re: syzkaller@googlegroups.com

[Darrick J. Wong]

[+linux-xfs]

On Tue, Jun 28, 2022 at 02:27:36PM -0500, Ayushman Dutta wrote:
> Kernel Version: 5.10.122
> 
> Kernel revision: 58a0d94cb56fe0982aa1ce9712e8107d3a2257fe
> 
> Syzkaller Dashboard report:
> 
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 8503 at mm/util.c:618 kvmalloc_node+0x15a/0x170
> mm/util.c:618

No.  Do not DM your syzbot reports to random XFS developers.

Especially do not send me *three message* with 300K of attachments; even
the regular syzbot runners dump all that stuff into a web portal.

If you are going to run some scripted tool to randomly
corrupt the filesystem to find failures, then you have an
ethical and moral responsibility to do some of the work to
narrow down and identify the cause of the failure, not just
throw them at someone else to do all the work.

> Modules linked in:
> CPU: 1 PID: 8503 Comm: syz-executor.4 Not tainted 5.10.122 #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
> 04/01/2014
> RIP: 0010:kvmalloc_node+0x15a/0x170 mm/util.c:618
> Code: ed 41 81 cd 00 20 01 00 e9 6c ff ff ff e8 ae 3c e5 ff 81 e5 00 20 00
> 00 31 ff 89 ee e8 ff 35 e5 ff 85 ed 75 cc e8 96 3c e5 ff <0f> 0b e9 e8 fe
> ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00
> RSP: 0018:ffffc9000900fa08 EFLAGS: 00010286
> RAX: 0000000000000081 RBX: 1ffff92001201f4a RCX: ffffffff815c3a3a
> RDX: 0000000000040000 RSI: ffffc90001921000 RDI: 0000000000000005
> RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000001 R12: 00000008cc977340
> R13: 0000000000000000 R14: 00000000ffffffff R15: 000000004664bb9a
> FS:  00007f8adb097640(0000) GS:ffff88806cf00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007ffdd5a73fc8 CR3: 0000000016dc6000 CR4: 0000000000750ee0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> PKRU: 55555554
> Call Trace:
>  kvmalloc include/linux/mm.h:765 [inline]
>  kvzalloc include/linux/mm.h:773 [inline]
>  xfs_ioc_getbmap+0x1f8/0x5f0 fs/xfs/xfs_ioctl.c:1695
>  xfs_file_ioctl+0x6c4/0x1a08 fs/xfs/xfs_ioctl.c:2157
>  vfs_ioctl fs/ioctl.c:48 [inline]
>  __do_sys_ioctl fs/ioctl.c:753 [inline]
>  __se_sys_ioctl fs/ioctl.c:739 [inline]
>  __x64_sys_ioctl+0x196/0x202 fs/ioctl.c:739
>  do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
>  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7f8adbf2392d
> Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f8adb097028 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 00007f8adc043f60 RCX: 00007f8adbf2392d
> RDX: 0000000020000000 RSI: 00000000c020582c RDI: 0000000000000003
> RBP: 00007f8adbf94070 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 0000000000000006 R14: 00007f8adc043f60 R15: 00007f8adb077000
> 
> 
> Syzkaller repro.txt
> 
> r0 = creat(&(0x7f0000000080)='./file0\x00', 0x0)
> ioctl$XFS_IOC_GETBMAPA(r0, 0xc020582c, &(0x7f0000000000)={0x0, 0x0, 0x0,
> 0x4664bb9a})
> 
> 
> Syzkaller repro.c
> 
> // autogenerated by syzkaller (https://github.com/google/syzkaller)
> 
> 
> #define _GNU_SOURCE
> 
> #include <endian.h>
> #include <stdint.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <sys/syscall.h>
> #include <sys/types.h>
> #include <unistd.h>
> 
> uint64_t r[1] = {0xffffffffffffffff};
> 
> int main(void)
> {
>   syscall(__NR_mmap, 0x1ffff000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
>   syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 7ul, 0x32ul, -1, 0ul);
>   syscall(__NR_mmap, 0x21000000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
>   intptr_t res = 0;
>   memcpy((void*)0x20000080, "./file0\000", 8);
>   res = syscall(__NR_creat, 0x20000080ul, 0ul);
>   if (res != -1)
>     r[0] = res;
>   *(uint64_t*)0x20000000 = 0;
>   *(uint64_t*)0x20000008 = 0;
>   *(uint64_t*)0x20000010 = 0;
>   *(uint32_t*)0x20000018 = 0x4664bb9a;
>   *(uint32_t*)0x2000001c = 0;

Sentient Google AI still unable to implement parameter decoding.

--D

>   syscall(__NR_ioctl, r[0], 0xc020582c, 0x20000000ul);
>   return 0;
> }
> 
> Config Attached.

Re: syzkaller@googlegroups.com

[Dave Chinner]

On Tue, Jun 28, 2022 at 03:07:51PM -0700, Darrick J. Wong wrote:
> [+linux-xfs]
> 
> On Tue, Jun 28, 2022 at 02:27:36PM -0500, Ayushman Dutta wrote:
> > Kernel Version: 5.10.122
> > 
> > Kernel revision: 58a0d94cb56fe0982aa1ce9712e8107d3a2257fe
> > 
> > Syzkaller Dashboard report:
> > 
> > ------------[ cut here ]------------
> > WARNING: CPU: 1 PID: 8503 at mm/util.c:618 kvmalloc_node+0x15a/0x170
> > mm/util.c:618
> 
> No.  Do not DM your syzbot reports to random XFS developers.
> 
> Especially do not send me *three message* with 300K of attachments; even
> the regular syzbot runners dump all that stuff into a web portal.
> 
> If you are going to run some scripted tool to randomly
> corrupt the filesystem to find failures, then you have an
> ethical and moral responsibility to do some of the work to
> narrow down and identify the cause of the failure, not just
> throw them at someone else to do all the work.

/me reads the stack trace, takes 30s to look at the change log,
finds commit 29d650f7e3ab ("xfs: reject crazy array sizes being fed
to XFS_IOC_GETBMAP*").

-Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: syzkaller@googlegroups.com

[Amir Goldstein]

On Wed, Jun 29, 2022 at 1:52 AM Dave Chinner <david@fromorbit.com> wrote:
>
> On Tue, Jun 28, 2022 at 03:07:51PM -0700, Darrick J. Wong wrote:
> > [+linux-xfs]
> >
> > On Tue, Jun 28, 2022 at 02:27:36PM -0500, Ayushman Dutta wrote:
> > > Kernel Version: 5.10.122
> > >
> > > Kernel revision: 58a0d94cb56fe0982aa1ce9712e8107d3a2257fe
> > >
> > > Syzkaller Dashboard report:
> > >
> > > ------------[ cut here ]------------
> > > WARNING: CPU: 1 PID: 8503 at mm/util.c:618 kvmalloc_node+0x15a/0x170
> > > mm/util.c:618
> >
> > No.  Do not DM your syzbot reports to random XFS developers.
> >
> > Especially do not send me *three message* with 300K of attachments; even
> > the regular syzbot runners dump all that stuff into a web portal.
> >
> > If you are going to run some scripted tool to randomly
> > corrupt the filesystem to find failures, then you have an
> > ethical and moral responsibility to do some of the work to
> > narrow down and identify the cause of the failure, not just
> > throw them at someone else to do all the work.
>
> /me reads the stack trace, takes 30s to look at the change log,
> finds commit 29d650f7e3ab ("xfs: reject crazy array sizes being fed
> to XFS_IOC_GETBMAP*").
>

I don't have the syzbot link here, but I assume this is reproducible
and not reproducing on mainline, so in fact syzbot should be capable
of finding the fix commit itself.

If syzbot can hear me, next time you find an xfs bug that is reproducible
on 5.10.y and not on mainline, you may send it to me.

Darrick, if you want to find a creative way to encode that request
in MAINTAINERS as you suggested, that is fine by me.
It should be something that makes it easy to teach the few bots that run
on LTS kernels to find the right recipients and spam us instead of you.
We could add a P: Subsystem Profile document, which contains stable
maintainers info but that is less robot friendly.
I don't have a better idea.

This fix patch is in my xfs-5.10.y queue - it will probably take several
weeks/month until it gets reviewed. I could expedite it if anyone
feels that I should.

Thanks,
Amir.

Re: syzkaller@googlegroups.com

[Darrick J. Wong]

On Wed, Jun 29, 2022 at 07:32:43AM +0300, Amir Goldstein wrote:
> On Wed, Jun 29, 2022 at 1:52 AM Dave Chinner <david@fromorbit.com> wrote:
> >
> > On Tue, Jun 28, 2022 at 03:07:51PM -0700, Darrick J. Wong wrote:
> > > [+linux-xfs]
> > >
> > > On Tue, Jun 28, 2022 at 02:27:36PM -0500, Ayushman Dutta wrote:
> > > > Kernel Version: 5.10.122
> > > >
> > > > Kernel revision: 58a0d94cb56fe0982aa1ce9712e8107d3a2257fe
> > > >
> > > > Syzkaller Dashboard report:
> > > >
> > > > ------------[ cut here ]------------
> > > > WARNING: CPU: 1 PID: 8503 at mm/util.c:618 kvmalloc_node+0x15a/0x170
> > > > mm/util.c:618
> > >
> > > No.  Do not DM your syzbot reports to random XFS developers.
> > >
> > > Especially do not send me *three message* with 300K of attachments; even
> > > the regular syzbot runners dump all that stuff into a web portal.
> > >
> > > If you are going to run some scripted tool to randomly
> > > corrupt the filesystem to find failures, then you have an
> > > ethical and moral responsibility to do some of the work to
> > > narrow down and identify the cause of the failure, not just
> > > throw them at someone else to do all the work.
> >
> > /me reads the stack trace, takes 30s to look at the change log,
> > finds commit 29d650f7e3ab ("xfs: reject crazy array sizes being fed
> > to XFS_IOC_GETBMAP*").
> >
> 
> I don't have the syzbot link here, but I assume this is reproducible
> and not reproducing on mainline, so in fact syzbot should be capable
> of finding the fix commit itself.
> 
> If syzbot can hear me, next time you find an xfs bug that is reproducible
> on 5.10.y and not on mainline, you may send it to me.

I suspect this guy is /not/ affiliated with the actual googlers who run
syzbot internally, which is why there's no link to their web app.

> Darrick, if you want to find a creative way to encode that request
> in MAINTAINERS as you suggested, that is fine by me.
> It should be something that makes it easy to teach the few bots that run
> on LTS kernels to find the right recipients and spam us instead of you.
> We could add a P: Subsystem Profile document, which contains stable
> maintainers info but that is less robot friendly.
> I don't have a better idea.

Yeah, I'll email the rest of the xfs lts cabal about that.

> This fix patch is in my xfs-5.10.y queue - it will probably take several
> weeks/month until it gets reviewed. I could expedite it if anyone
> feels that I should.

I don't care, but the people who think that /any/ backtrace in dmesg
might, even though this one in particular logs the warning and returns
ENOMEM.

--D

> Thanks,
> Amir.