bad config syzkaller param: can't find /syzkaller/jobs-2/netbsd/gopath/src/github.com/google/syzkaller/bin/netbsd_amd64/syz-executor

[Taylor R Campbell]

Looks like syzkaller is having trouble running NetBSD jobs again?

https://syzkaller.appspot.com/text?tag=Error&x=17eb5d3fc80000

Also these happened recently:

https://syzkaller.appspot.com/bug?id=37e29f3bd0d5b079e83f3de8f9d1097b31ff9372
https://syzkaller.appspot.com/bug?id=4249b3e5580fa2ff09cbf6a3d44b7731efafb83e

Doesn't look like anything NetBSD-specific, if I understand correctly?

[Aleksandr Nogikh]

On Wed, Apr 19, 2023 at 10:11 AM Taylor R Campbell <rias...@netbsd.org> wrote:
>
> Looks like syzkaller is having trouble running NetBSD jobs again?
>
> https://syzkaller.appspot.com/text?tag=Error&x=17eb5d3fc80000

Thank you for reporting!
Indeed, there seem to be some problems. I've looked into that for some
time and filed https://github.com/google/syzkaller/issues/3819. I'll
let you know when it's fixed.

>
> Also these happened recently:
>
> https://syzkaller.appspot.com/bug?id=37e29f3bd0d5b079e83f3de8f9d1097b31ff9372

This one looks more like some memory corruption.

> https://syzkaller.appspot.com/bug?id=4249b3e5580fa2ff09cbf6a3d44b7731efafb83e

At that line we allocate a slice of the same size, as some other slice had:
calls := make([]*Call, len(origCalls))

So len(origCalls) was either < 0 or more than the maximum allowed for
a slice (which shouldn't have happened -- as it's an existing slice
that was passed there). So it's also a result of some memory
corruption.

It's interesting that there are many "pmap_unwire: wiring for pmap
<...> did not change!"-like messages in logs for both bugs [1] [2].
What does it mean?

[1] https://syzkaller.appspot.com/text?tag=CrashLog&x=1455193fc80000
[2] https://syzkaller.appspot.com/text?tag=CrashLog&x=15e5f9b7c80000

--
Aleksandr

[Chuck Silvers]

On Wed, Apr 19, 2023 at 02:37:23PM +0200, 'Aleksandr Nogikh' via syzkaller-netbsd-bugs wrote:
> On Wed, Apr 19, 2023 at 10:11 AM Taylor R Campbell <rias...@netbsd.org> wrote:
> >
> > Looks like syzkaller is having trouble running NetBSD jobs again?
> >
> > https://syzkaller.appspot.com/text?tag=Error&x=17eb5d3fc80000
>
> Thank you for reporting!
> Indeed, there seem to be some problems. I've looked into that for some
> time and filed https://github.com/google/syzkaller/issues/3819. I'll
> let you know when it's fixed.
>
> >
> > Also these happened recently:
> >
> > https://syzkaller.appspot.com/bug?id=37e29f3bd0d5b079e83f3de8f9d1097b31ff9372
>
> This one looks more like some memory corruption.
>
> > https://syzkaller.appspot.com/bug?id=4249b3e5580fa2ff09cbf6a3d44b7731efafb83e
>
> At that line we allocate a slice of the same size, as some other slice had:
> calls := make([]*Call, len(origCalls))
>
> So len(origCalls) was either < 0 or more than the maximum allowed for
> a slice (which shouldn't have happened -- as it's an existing slice
> that was passed there). So it's also a result of some memory
> corruption.

one of the things the fuzzer is doing is this:

12:43:53 executing program 1:
compat_50_mknod(&(0x7f0000000000)='./file0\x00', 0x2001, 0x400)
r0 = open$dir(&(0x7f0000000000)='./file0\x00', 0x2, 0x0)
r1 = open$dir(&(0x7f0000000180)='./file0\x00', 0x0, 0x0)
r2 = dup2(r0, r1)
writev(r1, &(0x7f0000000340)=[{&(0x7f0000000000), 0x2cfea}], 0x1000000000000013)
r3 = socket(0x18, 0x1, 0x0)
setsockopt$sock_cred(r3, 0xffff, 0x11, 0x0, 0x0)
write(r2, &(0x7f0000000380)="a44531243b36459628c035868124e3ccfd36d8f8fa641ed0a193d02206091b96677415fdb1b35fc5fda1686288f75af544cb1d1bda8ca92170c2246188ec5a6afae9e93731d89f47d93d61ad3f83b603ab52af59b1e2a8802bcc6cc43e6b73cc84b2765d11e670055d76e0db780e341c2178fcd6ca0f19b752e5ee74cfa41fa8be50d3e3a5cc7a8da55425db05a7321bf9620f3805f5fd4e733b94c6d8d0b2916bd64c66cd68a541a4dd7c733d245e13a5e7a16327cb7d1ec4c52e9192b36e09ef02e8ee9f160f6fa5be8fe3c33f02a18d77392cfcbc803d9e898547df4e8b59c423dece83b2f046152ec930dc44afcf252935b408eb21f9204817958c20eeafb7a592f4b28000f1ef61c1a336b172bc819d90972a32b9075db503a8b65e9aa4d7ce054771fa21765f1f0fb0b805d0f4e9a6b494521e7febf40bd6d7e7d33920cb8216c5d5c37c2eb7b971ee75134bbdb606b72f63cff062d08d3411ae2eea5c3f64151d2200f96b9b6d636cb1f0f799d59984bb61bbfc8a57ed7bbd8a52149ba25fe0268f787986b78a51876a228ece025d07826c7c7ca1356fc10221ecbc7ce7cdad4ef68836ac9644934bfc0ca2d40259170599b30ae38ac334df11c14e84b6e0d015f1a5382b15003c8043530ff404f754527c1f05fca76a5538a1fe111aa2d98a92633e1613dd14c8f348cf6cff8930569f48647e3818e78419c554c069", 0x104d00)


this creates a character device node equivalent to /dev/drum (which is a
virtual device giving access to the OS swap space on disk) and writes to it.
if any of the fuzzer user memory has been paged out, when after the data
in swap on disk is overwritten, when the fuzzer accesses that page again,
the bogus data that the fuzzer wrote to swap will be what is read back in.

I found a mail thread from last year that talks about this:

https://groups.google.com/g/syzkaller-netbsd-bugs/c/1jk2EBjW4PI/m/HsqTQ-E9AgAJ

this thread includes a mention of netbsd having another syscall that is
a variation of mknod, called "compat_50_mknod", which is what is being
used in these runs that crash with memory corruption. the code in
sys/targets/common.go applies the mode checks for "mknod" and "mknodat",
but not for "compat_50_mknod". does this additional syscall name need to
be added to sys/targets/common.go? or is there something else
that maps "compat_50_mknod" to "mknod" before the info is given
to this neutralize code?

-Chuck

[Taylor R Campbell]

> Date: Wed, 19 Apr 2023 14:37:23 +0200
> From: Aleksandr Nogikh <nog...@google.com>

>
> On Wed, Apr 19, 2023 at 10:11 AM Taylor R Campbell <rias...@netbsd.org> wrote:
> >
> > Looks like syzkaller is having trouble running NetBSD jobs again?
> >
> > https://syzkaller.appspot.com/text?tag=Error&x=17eb5d3fc80000
>
> Thank you for reporting!
> Indeed, there seem to be some problems. I've looked into that for some
> time and filed https://github.com/google/syzkaller/issues/3819. I'll
> let you know when it's fixed.

Great, thanks!

> It's interesting that there are many "pmap_unwire: wiring for pmap
> <...> did not change!"-like messages in logs for both bugs [1] [2].
> What does it mean?
>
> [1] https://syzkaller.appspot.com/text?tag=CrashLog&x=1455193fc80000
> [2] https://syzkaller.appspot.com/text?tag=CrashLog&x=15e5f9b7c80000

Both logs have this line in it, followed by opening and writing to
this file:

compat_50_mknod(&(0x7f0000000000)='./file0\x00', 0x2001, 0x400)

As Chuck explained, this creates a device node mapping the swap space;
if any swap files or devices are configured, writing to this device
node would likely corrupt userland process memory and/or crash
processes. So I think both of these crash logs are red herrings.

[Aleksandr Nogikh]

On Wed, Apr 19, 2023 at 9:47 PM Taylor R Campbell <rias...@netbsd.org> wrote:
>
> > Date: Wed, 19 Apr 2023 14:37:23 +0200
> > From: Aleksandr Nogikh <nog...@google.com>
> >
> > On Wed, Apr 19, 2023 at 10:11 AM Taylor R Campbell <rias...@netbsd.org> wrote:
> > >
> > > Looks like syzkaller is having trouble running NetBSD jobs again?
> > >
> > > https://syzkaller.appspot.com/text?tag=Error&x=17eb5d3fc80000
> >
> > Thank you for reporting!
> > Indeed, there seem to be some problems. I've looked into that for some
> > time and filed https://github.com/google/syzkaller/issues/3819. I'll
> > let you know when it's fixed.
>
> Great, thanks!

I've fixed the problem, so patch testing should be working fine now.

>
> > It's interesting that there are many "pmap_unwire: wiring for pmap
> > <...> did not change!"-like messages in logs for both bugs [1] [2].
> > What does it mean?
> >
> > [1] https://syzkaller.appspot.com/text?tag=CrashLog&x=1455193fc80000
> > [2] https://syzkaller.appspot.com/text?tag=CrashLog&x=15e5f9b7c80000
>
> Both logs have this line in it, followed by opening and writing to
> this file:
>
> compat_50_mknod(&(0x7f0000000000)='./file0\x00', 0x2001, 0x400)
>
> As Chuck explained, this creates a device node mapping the swap space;
> if any swap files or devices are configured, writing to this device
> node would likely corrupt userland process memory and/or crash
> processes. So I think both of these crash logs are red herrings.

Thanks for the details!
I've sent a PR that enables call sanitization for compat_50_mknod:
https://github.com/google/syzkaller/pull/3826

Could you please confirm that

compat_50_mknod(&(0x7f0000000000)='./file0\x00', 0x2001, 0x400)

->
compat_50_mknod(&(0x7f0000000000)='./file0\x00', 0x8001, 0x400)
is a reasonable replacement?

--
Aleksandr

>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-netbsd-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-netbsd...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-netbsd-bugs/20230419194728.2A4366086C%40jupiter.mumble.net.