kernel: protection fault trap, code=0

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit: 25236b556a2d sync
git tree: https://github.com/openbsd/src.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=11dde8fb400000
dashboard link: https://syzkaller.appspot.com/bug?extid=de8d2459ecf4cdc576a1
compiler:

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+de8d24...@syzkaller.appspotmail.com

kernel: protection fault trap, code=0
Stopped at m_tag_delete_chain+0x25: movq 0(%r15),%rax


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.

[Greg Steuck]

Looks like the quality of error reports went down considerably as of late. We don't even get a stack trace much less a list of processes.

@Dmitry Vyukov, I don't suppose this is a known limitation of running on GCE? Maybe some kind of gce/openbsd kernel interaction?

--
You received this message because you are subscribed to the Google Groups "syzkaller-openbsd-bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-openbsd...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-openbsd-bugs/0000000000002915bb057bd60576%40google.com.
For more options, visit https://groups.google.com/d/optout.

--

nest.cx is Gmail hosted, use PGP for anything private. Key: http://goo.gl/6dMsr
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3  4D50 0B15 42BD 8DF5 A1B0

[Dmitry Vyukov]

On Fri, Nov 30, 2018 at 12:42 AM, Greg Steuck <gr...@nest.cx> wrote:
> Looks like the quality of error reports went down considerably as of late.
> We don't even get a stack trace much less a list of processes.
> @Dmitry Vyukov, I don't suppose this is a known limitation of running on
> GCE? Maybe some kind of gce/openbsd kernel interaction?

All of linux works on GCE too, so console should work.
We actually do get stack traces, crashes with stacks just fall into
other already reported bugs. And new bugs are long tail freak show of
corrupted/intermixed output. On linux we detect such reports and they
fall into a separate bucket:
https://syzkaller.appspot.com/bug?id=d5bc3e0c66d200d72216ab343a67c4327e4a3452

Re process list, that was qemu-specific code. vm/gce does not have
anything like this.

> https://groups.google.com/d/msgid/syzkaller-openbsd-bugs/CANMcDo9X-A-SEiohSKsiU5duDGFGg73YJL%2ByU3pY7ZeRkKmqSg%40mail.gmail.com.

[syzbot]

syzbot has found a reproducer for the following crash on:

HEAD commit: e9b93a3e5ebc Remove erroneous quote added in previous

git tree: https://github.com/openbsd/src.git master

console output: https://syzkaller.appspot.com/x/log.txt?x=17c81c25400000

dashboard link: https://syzkaller.appspot.com/bug?extid=de8d2459ecf4cdc576a1
compiler:

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1670a843400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1230ddeb400000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+de8d24...@syzkaller.appspotmail.com

login: kernel: protection fault trap, code=0
Stopped at m_extfree+0x3d: movq %rax,0x90(%r15)
ddb>
ddb> set $lines = 0
ddb> show panic
the kernel did not panic
ddb> trace
m_extfree(eeae323926dacfb9) at m_extfree+0x3d
m_free(ffffff006e3b2800) at m_free+0xee
m_freem(16) at m_freem+0x2d
soreceive(0,ffffff006e708908,0,0,ffff8000210fa960,ffff8000210fa870) at
soreceive+0x1131
recvit(ffff8000210fa990,ffff8000210faa98,ffff8000210faa80,ffff8000210c3078,0)
at
recvit+0x28c
sys_recvmsg(ffff8000210fab20,ffff8000210c3078,ffff8000210a5660) at
sys_recvmsg+0x120
syscall(0) at syscall+0x3e4
Xsyscall(6,0,0,0,1,7f7ffffd8118) at Xsyscall+0x128
end of kernel
end trace frame: 0x7f7ffffd80d0, count: -8
ddb> show registers
rdi 0x7
rsi 0x42
rbp 0xffff8000210fa760
rbx 0
rdx 0x4110 __ALIGN_SIZE+0x3110
rcx 0xffffffff81e5dcc0 mbstat_boot_boot_cpumem
rax 0xe1311bd068d226d1
r8 0
r9 0xffff8000210c3078
r10 0xeeae323926dacfb9
r11 0xffffffff815aaa10 pool_lock_mtx_leave
r12 0xdead __ALIGN_SIZE+0xcead
r13 0xffffff006e708908
r14 0xffffff006e3b2800
r15 0x19fd241911c88e48
rip 0xffffffff8151b69d m_extfree+0x3d
cs 0x8
rflags 0x10246 __ALIGN_SIZE+0xf246
rsp 0xffff8000210fa750
ss 0x10
m_extfree+0x3d: movq %rax,0x90(%r15)
ddb> show proc
PROC (syz-executor2746) pid=43702 stat=onproc
flags process=2<EXEC> proc=0
pri=50, usrpri=50, nice=20
forw=0xffffffffffffffff, list=0xffff8000210c32d0,0xffffffff81e98cf0
process=0xffff8000210a5660 user=0xffff8000210f5000,
vmspace=0xffffff007f12b738
estcpu=0, cpticks=0, pctcpu=0.0
user=0, sys=0, intr=0
ddb> ps
PID TID PPID UID S FLAGS WAIT COMMAND
*79018 43702 95832 0 7 0x2 syz-executor2746
95832 427331 55680 0 3 0x10008a pause ksh
55680 313355 24267 0 3 0x92 select sshd
10602 288144 1 0 3 0x100083 ttyin getty
24267 237753 1 0 3 0x80 select sshd
90806 332710 7968 73 3 0x100090 kqread syslogd
7968 520884 1 0 3 0x100082 netio syslogd
88963 201487 1 77 3 0x100090 poll dhclient
12226 54954 1 0 3 0x80 poll dhclient
16290 426033 0 0 2 0x14200 zerothread
78023 377457 0 0 3 0x14200 aiodoned aiodoned
65835 304055 0 0 3 0x14200 syncer update
25536 172965 0 0 3 0x14200 cleaner cleaner
52190 319551 0 0 3 0x14200 reaper reaper
95903 297620 0 0 3 0x14200 pgdaemon pagedaemon
67386 496933 0 0 3 0x14200 bored crynlk
78545 3126 0 0 3 0x14200 bored crypto
24821 162148 0 0 3 0x40014200 acpi0 acpi0
44462 326116 0 0 3 0x14200 bored softnet
67132 455602 0 0 3 0x14200 bored systqmp
23929 228998 0 0 3 0x14200 bored systq
68458 210791 0 0 3 0x40014200 bored softclock
45918 497678 0 0 3 0x40014200 idle0
1 494986 0 0 3 0x82 wait init
0 0 -1 0 3 0x10200 scheduler swapper
ddb>

[Greg Steuck]

Hey Claudio,

You seem to have touched soreceive recently and probably would know how the code fails to account for the reproducer which we found.

When running against GENERIC.MP I got the following error instead of the one that was originally found by syzkaller, but it's probably just a somewhat different set of conditions due to instrumentation.

login: panic: m_zero: M_READONLY

Stopped at      db_enter+0x12:  popq    %r11

    TID    PID    UID     PRFLAGS     PFLAGS  CPU  COMMAND

* 19313  61843      0         0x3          0    4  mext_free

db_enter() at db_enter+0x12

panic() at panic+0x120

m_free(1a854384c072d750) at m_free+0x132

m_freem(f3ce5b4eae8be08a) at m_freem+0x28

soreceive(478b9f2d7b2f4967,ffff800022162f4c,0,0,0,0) at soreceive+0x1b5

recvit(896bac55e0189c40,ffff8000222044d0,ffff800022163068,ffff800022163050,ffff

800022162f50) at recvit+0x1e2

sys_recvmsg(ad6657c23f6e4274,1b0,ffff8000222044d0) at sys_recvmsg+0x100

syscall(92311230841cf061) at syscall+0x32a

Xsyscall(6,0,0,0,20001348,20001350) at Xsyscall+0x128

end of kernel

end trace frame: 0x7f7fffff9670, count: 6