kernel BUG at net/core/skbuff.c:LINE! (3)

[syzbot]

Hello,

syzbot hit the following crash on net-next commit
b2fe5fa68642860e7de76167c3111623aa0d5de1 (Wed Jan 31 22:31:10 2018 +0000)
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next

Unfortunately, I don't have any reproducer for this crash yet.
Raw console output is attached.
compiler: gcc (GCC) 7.1.1 20170620
.config is attached.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+b2bf26...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.

skbuff: skb_over_panic: text:000000004b89f3be len:66136 put:66124
head:00000000f255561a data:00000000ccb55e52 tail:0x10310 end:0x6c0
dev:<NULL>
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:104!
invalid opcode: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 19738 Comm: syz-executor3 Not tainted 4.15.0+ #219
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:skb_panic+0x162/0x1f0 net/core/skbuff.c:100
RSP: 0018:ffff8801c1a6e4e8 EFLAGS: 00010286
RAX: 000000000000008f RBX: ffff8801d0090000 RCX: 0000000000000000
RDX: 000000000000008f RSI: ffffc90003d53000 RDI: ffffed003834dc91
RBP: ffff8801c1a6e550 R08: 1ffff1003834dc1f R09: 0000000000000000
R10: 0000000000000004 R11: 0000000000000000 R12: ffffffff863fe4e0
R13: ffffffff85276640 R14: 000000000001024c R15: ffffffff863fdd20
FS: 00007f69cd01b700(0000) GS:ffff8801db500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000718008 CR3: 00000001c71c7006 CR4: 00000000001606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
skb_over_panic net/core/skbuff.c:109 [inline]
skb_put+0x18d/0x1d0 net/core/skbuff.c:1695
skb_put_data include/linux/skbuff.h:2049 [inline]
sctp_packet_pack net/sctp/output.c:473 [inline]
sctp_packet_transmit+0x1180/0x3750 net/sctp/output.c:606
sctp_outq_flush+0x121b/0x4060 net/sctp/outqueue.c:1197
sctp_outq_uncork+0x5a/0x70 net/sctp/outqueue.c:776
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1807 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1210 [inline]
sctp_do_sm+0x4e0/0x6ed0 net/sctp/sm_sideeffect.c:1181
sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
sctp_sendmsg+0x1894/0x35e0 net/sctp/socket.c:2029
inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:764
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:640
sock_write_iter+0x31a/0x5d0 net/socket.c:909
call_write_iter include/linux/fs.h:1781 [inline]
do_iter_readv_writev+0x55c/0x830 fs/read_write.c:653
do_iter_write+0x154/0x540 fs/read_write.c:932
vfs_writev+0x18a/0x340 fs/read_write.c:977
do_writev+0xfc/0x2a0 fs/read_write.c:1012
SYSC_writev fs/read_write.c:1085 [inline]
SyS_writev+0x27/0x30 fs/read_write.c:1082
entry_SYSCALL_64_fastpath+0x29/0xa0
RIP: 0033:0x453299
RSP: 002b:00007f69cd01ac58 EFLAGS: 00000212 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 000000000071bea0 RCX: 0000000000453299
RDX: 0000000000000001 RSI: 0000000020f7ffe0 RDI: 0000000000000013
RBP: 00000000000005c5 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f7b18
R13: 00000000ffffffff R14: 00007f69cd01b6d4 R15: 0000000000000000
Code: 04 01 84 c0 74 04 3c 03 7e 23 8b 8b 80 00 00 00 41 57 48 c7 c7 60 dd
3f 86 52 56 4c 89 ea 41 50 4c 89 e6 45 89 f0 e8 c6 d7 25 fd <0f> 0b 4c 89
4d b8 4c 89 45 c0 48 89 75 c8 48 89 55 d0 e8 47 53
RIP: skb_panic+0x162/0x1f0 net/core/skbuff.c:100 RSP: ffff8801c1a6e4e8
---[ end trace c7cd29819a9b12ab ]---


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzk...@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.

[syzbot]

syzbot has found reproducer for the following crash on upstream commit
f9f1e414128ea58d8e848a0275db0f644c9e9f45 (Fri Feb 9 18:07:39 2018 +0000)
Merge tag 'for-linus-4.16-rc1-tag' of
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip

So far this crash happened 2 times on net-next, upstream.
C reproducer is attached.
syzkaller reproducer is attached.

Raw console output is attached.
compiler: gcc (GCC) 7.1.1 20170620
.config is attached.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+b2bf26...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.

skbuff: skb_over_panic: text:000000008799e2ef len:1584 put:1584
head:0000000049a6d341 data:0000000017b26397 tail:0x6c8 end:0x6c0 dev:<NULL>

------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:104!
invalid opcode: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:

CPU: 1 PID: 4169 Comm: syzkaller206231 Not tainted 4.15.0+ #306

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:skb_panic+0x162/0x1f0 net/core/skbuff.c:100

RSP: 0018:ffff8801b13c6fd8 EFLAGS: 00010282
RAX: 000000000000008b RBX: ffff8801b66c4dc0 RCX: 0000000000000000
RDX: 000000000000008b RSI: 1ffff10036278db0 RDI: ffffed0036278def
RBP: ffff8801b13c7040 R08: 1ffff10036278d47 R09: 0000000000000000
R10: 0000000000000004 R11: 0000000000000000 R12: ffffffff86405e60
R13: ffffffff84c3af4c R14: 0000000000000630 R15: ffffffff864056a0
FS: 0000000000763880(0000) GS:ffff8801db500000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 0000000020024000 CR3: 00000001b2752005 CR4: 00000000001606e0

DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
skb_over_panic net/core/skbuff.c:109 [inline]
skb_put+0x18d/0x1d0 net/core/skbuff.c:1695

__ip6_append_data.isra.44+0x1edc/0x3390 net/ipv6/ip6_output.c:1443
ip6_append_data+0x189/0x290 net/ipv6/ip6_output.c:1571
rawv6_sendmsg+0x1e09/0x40c0 net/ipv6/raw.c:928

inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:764
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:640

___sys_sendmsg+0x767/0x8b0 net/socket.c:2046
__sys_sendmsg+0xe5/0x210 net/socket.c:2080
SYSC_sendmsg net/socket.c:2091 [inline]
SyS_sendmsg+0x2d/0x50 net/socket.c:2087
do_syscall_64+0x282/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x26/0x9b
RIP: 0033:0x4456c9
RSP: 002b:00007ffe43f8afa8 EFLAGS: 00000217 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: ffffffffffffffff RCX: 00000000004456c9
RDX: 0000000000008000 RSI: 0000000020000000 RDI: 0000000000000004
RBP: 00000000004a7273 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000217 R12: 0000000000402800
R13: 0000000000402890 R14: 0000000000000000 R15: 0000000000000000
Code: 04 01 84 c0 74 04 3c 03 7e 23 8b 8b 80 00 00 00 41 57 48 c7 c7 e0 56
40 86 52 56 4c 89 ea 41 50 4c 89 e6 45 89 f0 e8 d6 63 22 fd <0f> 0b 4c 89
4d b8 4c 89 45 c0 48 89 75 c8 48 89 55 d0 e8 f7 0e
RIP: skb_panic+0x162/0x1f0 net/core/skbuff.c:100 RSP: ffff8801b13c6fd8
---[ end trace e2ebe6f48e7f5b6c ]---

[Xin Long]

On Fri, Feb 2, 2018 at 3:21 AM, syzbot
<syzbot+b2bf26...@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot hit the following crash on net-next commit
> b2fe5fa68642860e7de76167c3111623aa0d5de1 (Wed Jan 31 22:31:10 2018 +0000)
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
>
> Unfortunately, I don't have any reproducer for this crash yet.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+b2bf26...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> skbuff: skb_over_panic: text:000000004b89f3be len:66136 put:66124
> head:00000000f255561a data:00000000ccb55e52 tail:0x10310 end:0x6c0
> dev:<NULL>

From the raw log, it should be a data chunk.
But I couldn't see how len:66136 happened?
considering that frag_point is always smaller than SCTP_MAX_CHUNK_LEN.

[Dmitry Vyukov]

On Sat, Feb 10, 2018 at 12:17 PM, Xin Long <lucie...@gmail.com> wrote:
> On Fri, Feb 2, 2018 at 3:21 AM, syzbot
> <syzbot+b2bf26...@syzkaller.appspotmail.com> wrote:
>> Hello,
>>
>> syzbot hit the following crash on net-next commit
>> b2fe5fa68642860e7de76167c3111623aa0d5de1 (Wed Jan 31 22:31:10 2018 +0000)
>> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
>>
>> Unfortunately, I don't have any reproducer for this crash yet.
>> Raw console output is attached.
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached.
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+b2bf26...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> skbuff: skb_over_panic: text:000000004b89f3be len:66136 put:66124
>> head:00000000f255561a data:00000000ccb55e52 tail:0x10310 end:0x6c0
>> dev:<NULL>
> From the raw log, it should be a data chunk.
> But I couldn't see how len:66136 happened?
> considering that frag_point is always smaller than SCTP_MAX_CHUNK_LEN.

William, Meenakshi,

This crash was bisected to:

commit 84e54fe0a5eaed696dee4019c396f8396f5a908b
Author: William Tu <u901...@gmail.com>
Date: Tue Aug 22 09:40:28 2017 -0700

gre: introduce native tunnel support for ERSPAN

bisection log:
https://gist.githubusercontent.com/dvyukov/a9661d43b2b519b91540f7466dbc32c1/raw/8df343224177933c8c398be126bb82be99aa0b4b/gistfile1.txt

[L. Alberto Giménez]

Hi,

I'm kind of "triaging"/checking if I can reproduce some of the bugs, but I can't reproduce this particular one in a qemu VM.

I compiled a kernel from commit 786b71f5b754273ccef6d9462e52062b3e1f9877 "Merge tag 'nds32-for-linus-4.17-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/greentime/linux" but I got this output from the C repro:

------------------------ 8< --------------------------------------

# ./repro

net.ipv6.conf.syz0.accept_dad = 0

net.ipv6.conf.syz0.router_solicitations = 0

RTNETLINK answers: Operation not supported

RTNETLINK answers: Operation not supported

Invalid address length 6 - must be 4 bytes

Cannot find device "vcan0"

Cannot find device "vcan0"

Cannot find device "vcan0"

Cannot find device "vcan0"

Cannot find device "tunl0"

Cannot find device "tunl0"

Cannot find device "tunl0"

Cannot find device "tunl0"

Cannot find device "gre0"

Cannot find device "gre0"

Cannot find device "gre0"

Cannot find device "gre0"

Cannot find device "gretap0"

Cannot find device "gretap0"

Cannot find device "gretap0"

Cannot find device "gretap0"

Cannot find device "ip_vti0"

Cannot find device "ip_vti0"

Cannot find device "ip_vti0"

Cannot find device "ip_vti0"

Cannot find device "ip6_vti0"

Cannot find device "ip6_vti0"

Cannot find device "ip6_vti0"

Cannot find device "ip6_vti0"

Cannot find device "ip6tnl0"

Cannot find device "ip6tnl0"

Cannot find device "ip6tnl0"

Cannot find device "ip6tnl0"

Cannot find device "ip6gre0"

Cannot find device "ip6gre0"

Cannot find device "ip6gre0"

Cannot find device "ip6gre0"

Cannot find device "ip6gretap0"

Cannot find device "ip6gretap0"

Cannot find device "ip6gretap0"

Cannot find device "ip6gretap0"

Cannot find device "erspan0"

Cannot find device "erspan0"

Cannot find device "erspan0"

Cannot find device "erspan0"

------------------------ 8< --------------------------------------

Am I doing something wrong here?

Thanks,

L. Alberto

 

[Dmitry Vyukov]

Hi,

Did you use the provided config? Most of the devices referenced as
"Cannot find device" must be present with the config.

> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bug...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/e1430282-7fd0-49dc-a83b-0a2e57d76a9c%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[L. Alberto Giménez]

On Mon, Jun 04, 2018 at 07:55:45AM +0200, 'Dmitry Vyukov' via syzkaller-bugs wrote:
> On Sat, Jun 2, 2018 at 8:58 PM, L. Alberto Giménez <agim...@sysvalve.es> wrote:
> > I'm kind of "triaging"/checking if I can reproduce some of the bugs, but I
> > can't reproduce this particular one in a qemu VM.
> >
> > I compiled a kernel from commit 786b71f5b754273ccef6d9462e52062b3e1f9877
> > "Merge tag 'nds32-for-linus-4.17-fixes' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/greentime/linux" but I got
> > this output from the C repro:
>
> Hi,
>
> Did you use the provided config? Most of the devices referenced as
> "Cannot find device" must be present with the config.
>

Hi,

I checked again, checked ouy from the last commit registered in the bug page
(https://syzkaller.appspot.com/bug?id=9c55af67ce995cf6c4f11ab6f5d3ee805d67fc00). The
commit is 13405468f49d4b6e014fdf376f46393f9590769d "bpf ilter: don't pass O_CREAT when opening console for debug"

I double-checked the config file, made olddefconfig from that config, and ran the
reproducer in a KVM virtual machine with that kernel installed. No BUG whatsoever,
but got multiple repeated messages instead from the reproducer:

------------------------- 8< --------------------------------

Invalid address length 6 - must be 4 bytes
Invalid address length 6 - must be 4 bytes
Invalid address length 6 - must be 4 bytes

[...]
RTNETLINK answers: No buffer space available
RTNETLINK answers: No buffer space available

RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported

[...]

Invalid address length 6 - must be 4 bytes

Invalid address length 6 - must be 16 bytes
[...]
------------------------- >8 --------------------------------

I'm sure I'm missing something here, or I have some incompatible setup that prevents
the bug from showing.

Can someone confirm to be able to reproduce this? Should I start looking other
syzkaller bug?


Thanks

--
L. Alberto Giménez
GnuPG key ID 0xDD4E27AB

[Dmitry Vyukov]

I was able to trigger the BUG within a second in qemu.
I took exactly the provided commit
(f9f1e414128ea58d8e848a0275db0f644c9e9f45), the provided config and my
host gcc 7.3. You can take gcc 7 and image here:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce

# ./a.out
[ 167.982047] IPVS: ftp: loaded support on port[0] = 21

net.ipv6.conf.syz0.accept_dad = 0
net.ipv6.conf.syz0.router_solicitations = 0

RTNETLINK answers: Operation not supported

[ 168.157780] IPv6: ADDRCONF(NETDEV_UP): bridge0: link is not ready

RTNETLINK answers: No buffer space available
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported

RTNETLINK answers: Invalid argument
RTNETLINK answers: Invalid argument
RTNETLINK answers: Invalid argument
[ 168.423794] skbuff: skb_over_panic: text:0000000074e01e82 len:1584
put:1584 head:0000000006d4bda8 data:000000005921e788 tail:0x6c8
end:0x6c0 dev:<NULL>
[ 168.426581] ------------[ cut here ]------------
[ 168.427452] kernel BUG at net/core/skbuff.c:104!
[ 168.428341] invalid opcode: 0000 [#1] SMP KASAN
8 16
.M4es2sa9ge2 f0ro4m] M soysdlougdl@seyzska lllienr kate Jdun i7 n18::
4:37 .[..
1ke6r8.430269] CPU: 1 PID: 3588 Comm: a.out Not tainted 4.15.0+ #1
[ 168.431449] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.10.2-1 04/01/2014
[ 168.432975] RIP: 0010:skb_panic+0x162/0x1f0
[ 168.433770] RSP: 0018:ffff880062f4efd8 EFLAGS: 00010282
[ 168.434737] RAX: 000000000000008b RBX: ffff88006a8cf2c0 RCX: 0000000000000000
[ 168.436043] RDX: 000000000000008b RSI: 1ffff1000c5e9db0 RDI: ffffed000c5e9def
[ 168.437408] RBP: ffff880062f4f040 R08: 1ffff1000c5e9d47 R09: 0000000000000000
[ 168.438719] R10: 0000000000000004 R11: 0000000000000000 R12: ffffffff86405e60
[ 168.440032] R13: ffffffff84c540f8 R14: 0000000000000630 R15: ffffffff864056a0
[ 168.441348] FS: 00000000017a3880(0000) GS:ffff88006cc80000(0000)
knlGS:0000000000000000
[ 168.442827] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 168.443887] CR2: 0000000020024000 CR3: 000000006a70a005 CR4: 00000000001606e0
[ 168.445203] Call Trace:
[ 168.445683] ? skb_set_owner_w+0x330/0x330
[ 168.446453] ? __sys_sendmsg+0xe5/0x210
[ 168.447176] ? __ip6_append_data.isra.44+0x1ee8/0x33a0
[ 168.448133] skb_put+0x18d/0x1d0
[ 168.448746] __ip6_append_data.isra.44+0x1ee8/0x33a0
[ 168.449677] ? ip6_mtu+0x369/0x4d0
[ 168.450326] ? ip6_cork_release.isra.42+0x2c0/0x2c0
[ 168.451235] ? ip6_mtu+0x1c7/0x4d0
[ 168.451878] ? ip6_dst_ifdown+0x3d0/0x3d0
[ 168.452635] ? memcpy+0x45/0x50
[ 168.453245] ? ip6_setup_cork+0xebd/0x1750
[ 168.454013] ? ip6_dst_mtu_forward+0x3c0/0x3c0
[ 168.454841] ? lock_acquire+0x1d5/0x580
[ 168.455560] ? lock_sock_nested+0xa3/0x110
[ 168.456327] ? lock_acquire+0x1d5/0x580
[ 168.457048] ? rawv6_sendmsg+0x1d89/0x40c0
[ 168.457827] ip6_append_data+0x189/0x290
[ 168.458565] ? rawv6_mh_filter_unregister+0xd0/0xd0
[ 168.459478] ? rawv6_mh_filter_unregister+0xd0/0xd0
[ 168.460389] rawv6_sendmsg+0x1e0c/0x40c0
[ 168.461131] ? rawv6_bind+0x8c0/0x8c0
[ 168.461826] ? debug_check_no_locks_freed+0x3c0/0x3c0
[ 168.462760] ? do_raw_spin_trylock+0x190/0x190
[ 168.463602] ? _raw_spin_unlock_irqrestore+0x31/0xba
[ 168.464542] ? trace_hardirqs_on_caller+0x421/0x5c0
[ 168.465476] ? trace_hardirqs_on+0xd/0x10
[ 168.466242] ? depot_save_stack+0x2ca/0x460
[ 168.467030] ? save_stack+0xa3/0xd0
[ 168.467691] ? save_stack+0x43/0xd0
[ 168.468362] ? kasan_kmalloc+0xad/0xe0
[ 168.469059] ? __kmalloc+0x162/0x760
[ 168.469749] ? sock_kmalloc+0x112/0x190
[ 168.470474] ? ___sys_sendmsg+0x458/0x8b0
[ 168.471228] ? __sys_sendmsg+0xe5/0x210
[ 168.471949] ? SyS_sendmsg+0x2d/0x50
[ 168.472624] ? do_syscall_64+0x284/0x940
[ 168.473363] ? entry_SYSCALL_64_after_hwframe+0x26/0x9b
[ 168.474502] ? find_held_lock+0x35/0x1d0
[ 168.475217] ? check_noncircular+0x20/0x20
[ 168.475954] ? lock_downgrade+0x980/0x980
[ 168.476728] ? lock_release+0xa40/0xa40
[ 168.477503] ? find_held_lock+0x35/0x1d0
[ 168.478271] inet_sendmsg+0x124/0x5e0
[ 168.478967] ? rawv6_bind+0x8c0/0x8c0
[ 168.479662] ? inet_sendmsg+0x124/0x5e0
[ 168.480399] ? inet_create+0xf50/0xf50
[ 168.481125] ? __might_sleep+0x95/0x190
[ 168.481858] ? security_socket_sendmsg+0x8f/0xc0
[ 168.482745] ? inet_create+0xf50/0xf50
[ 168.483450] sock_sendmsg+0xcc/0x110
[ 168.484139] ___sys_sendmsg+0x769/0x8b0
[ 168.484845] ? copy_msghdr_from_user+0x590/0x590
[ 168.485737] ? do_raw_spin_unlock+0x1ec/0x300
[ 168.486553] ? __local_bh_enable_ip+0x121/0x230
[ 168.487401] ? trace_hardirqs_on_caller+0x421/0x5c0
[ 168.488324] ? release_sock+0x1d6/0x2a0
[ 168.489055] ? trace_hardirqs_on+0xd/0x10
[ 168.489819] ? __local_bh_enable_ip+0x121/0x230
[ 168.490671] ? _raw_spin_unlock_bh+0x30/0x40
[ 168.491476] ? __fget_light+0x2b2/0x3c0
[ 168.492203] ? fget_raw+0x20/0x20
[ 168.492834] ? lock_sock_nested+0x91/0x110
[ 168.493610] ? trace_hardirqs_on+0xd/0x10
[ 168.494366] ? __local_bh_enable_ip+0x121/0x230
[ 168.495224] ? ip6_datagram_connect+0x3a/0x50
[ 168.496044] ? ip6_datagram_connect_v6_only+0x66/0x80
[ 168.496996] __sys_sendmsg+0xe5/0x210
[ 168.497695] ? __sys_sendmsg+0xe5/0x210
[ 168.498422] ? SyS_shutdown+0x290/0x290
[ 168.499149] ? up_read+0x1a/0x40
[ 168.499772] ? move_addr_to_kernel+0x60/0x60
[ 168.500580] SyS_sendmsg+0x2d/0x50
[ 168.501231] ? __sys_sendmsg+0x210/0x210
[ 168.501976] do_syscall_64+0x284/0x940
[ 168.502687] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 168.503557] ? syscall_return_slowpath+0x550/0x550
[ 168.504457] ? syscall_return_slowpath+0x2ac/0x550
[ 168.505362] ? prepare_exit_to_usermode+0x350/0x350
[ 168.506277] ? entry_SYSCALL_64_after_hwframe+0x36/0x9b
[ 168.507256] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 168.508141] entry_SYSCALL_64_after_hwframe+0x26/0x9b
[ 168.509084] RIP: 0033:0x445ec9
[ 168.509671] RSP: 002b:00007ffc813934b8 EFLAGS: 00000246 ORIG_RAX:
000000000000002e
[ 168.511073] RAX: ffffffffffffffda RBX: 00000000004002f8 RCX: 0000000000445ec9
[ 168.512390] RDX: 0000000000008000 RSI: 0000000020000000 RDI: 0000000000000004
[ 168.513712] RBP: 00007ffc81393500 R08: 0000000020024020 R09: 00000000004900d0
[ 168.515031] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004029d0
[ 168.516347] R13: 0000000000402a60 R14: 0000000000000000 R15: 0000000000000000
[ 168.517674] Code: 04 01 84 c0 74 04 3c 03 7e 23 8b 8b 80 00 00 00
41 57 48 c7 c7 e0 56 40 86 52 56 4c 89 ea 41 50 4c 89 e6 45 89 f0 e8
d6 1a 21 fd <0f> 0b 4c 89 4d b8 4c 89 45 c0 48 89 75 c8 48 89 55 d0 e8
97 d5
[ 168.521230] RIP: skb_panic+0x162/0x1f0 RSP: ffff880062f4efd8
[ 168.522344] ---[ end trace 3cf44e685c545a64 ]---

[Dmitry Vyukov]

This exact reproducer does not trigger the crash on latest upstream for me.
However, syzbot claims this still happens:
https://syzkaller.appspot.com/bug?id=9c55af67ce995cf6c4f11ab6f5d3ee805d67fc00

The reproducer from May 24 triggered the crash on the latest upstream
(c90fca951e90ba470a3dc6087667edffcf8db21b) for me.
Maybe it's a different bug, and the old one was either fixed or
requires a different reproducer now...


[ 37.343767] ------------[ cut here ]------------
[ 37.344851] kernel BUG at net/core/skbuff.c:2643!
[ 37.345805] invalid opcode: 0000 [#1] SMP KASAN
[ 37.346677] CPU: 0 PID: 3534 Comm: a.out Not tainted 4.17.0+ #2
[ 37.347797] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.10.2-1 04/01/2014
[ 37.349346] RIP: 0010:skb_copy_and_csum_bits+0x5e4/0x6e0
[ 37.350332] Code: 49 63 c4 48 01 45 c8 01 45 b8 41 01 c5 e9 1d ff
ff ff 8b 5d d4 e8 0c 9f 26 fd 8b 45 c0 85 c0 0f 84 ab fe ff ff e8 fc
9e 26 fd <0f> 0b 45 31 ff e9 4c fb ff ff 8b 5d d4 e9 94 fe ff ff e8 e5
9e 26
[ 37.353898] RSP: 0018:ffff88002dc06220 EFLAGS: 00010206
[ 37.354874] RAX: ffff88007a46a640 RBX: 000000006485bc1a RCX: ffffffff844d49f4
[ 37.356191] RDX: 0000000000000100 RSI: ffff88002a1765cc RDI: ffff88002a1a4308
[ 37.357526] RBP: ffff88002dc062a0 R08: 0000000000000000 R09: 0000000000000000
[ 37.358841] R10: 000000000000003c R11: ffffed0005b80bef R12: ffff880029b2e068
[ 37.360157] R13: ffff88002132f980 R14: 00000000000001e8 R15: 000000000000003c
[ 37.361514] FS: 0000000001696940(0000) GS:ffff88002dc00000(0000)
knlGS:0000000000000000
[ 37.362992] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 37.364051] CR2: 00007f8c46d84db8 CR3: 000000007df16000 CR4: 00000000000006f0
[ 37.365383] Call Trace:
[ 37.365853] <IRQ>
[ 37.366254] ? save_stack+0xa3/0xd0
[ 37.366919] icmp_glue_bits+0x7f/0x1d0
[ 37.367629] __ip_append_data.isra.45+0x197c/0x2860
[ 37.368542] ? tcp_write_timer+0x153/0x170
[ 37.369314] ? run_timer_softirq+0x4c/0x70
[ 37.370088] ? do_syscall_64+0x18a/0x750
[ 37.370826] ? icmp_push_reply+0x4f0/0x4f0
[ 37.371616] ? __ip_flush_pending_frames.isra.41+0x2b0/0x2b0
[ 37.372685] ? __lock_is_held+0xb6/0x140
[ 37.373423] ? ipv4_mtu+0x411/0x580
[ 37.374078] ? __build_flow_key.constprop.52+0x630/0x630
[ 37.375064] ? rcu_read_lock_sched_held+0x108/0x120
[ 37.375970] ? kmem_cache_alloc_trace+0x491/0x750
[ 37.376867] ? icmp_route_lookup.constprop.23+0x462/0x1540
[ 37.377893] ip_append_data.part.46+0xde/0x150
[ 37.378727] ? icmp_push_reply+0x4f0/0x4f0
[ 37.379495] ? icmp_push_reply+0x4f0/0x4f0
[ 37.380265] ip_append_data+0x5a/0x80
[ 37.380963] icmp_push_reply+0x169/0x4f0
[ 37.381730] icmp_send+0x113c/0x19c0
[ 37.382409] ? icmp_route_lookup.constprop.23+0x1540/0x1540
[ 37.383444] ? nf_ct_deliver_cached_events+0x52e/0x750
[ 37.384400] ? lock_downgrade+0x980/0x980
[ 37.385169] ? nf_conntrack_update+0xb60/0xb60
[ 37.386004] ? kasan_check_read+0x11/0x20
[ 37.386762] ? rcu_gpnum_ovf+0x310/0x310
[ 37.387508] ? __build_flow_key.constprop.52+0x630/0x630
[ 37.388506] ? __lock_is_held+0xb6/0x140
[ 37.389250] ip_fragment.constprop.47+0x1ac/0x200
[ 37.390131] ip_finish_output+0x6a2/0xd70
[ 37.390886] ? ip_fragment.constprop.47+0x200/0x200
[ 37.391811] ? kasan_check_read+0x11/0x20
[ 37.392575] ? rcu_is_watching+0x85/0x130
[ 37.393328] ? rcu_gpnum_ovf+0x310/0x310
[ 37.394064] ? nf_hook_slow+0xd6/0x1b0
[ 37.394769] ip_output+0x1d2/0x860
[ 37.395411] ? ip_mc_output+0x1350/0x1350
[ 37.396165] ? ip_fragment.constprop.47+0x200/0x200
[ 37.397085] ip_local_out+0x9b/0x170
[ 37.397760] ip_queue_xmit+0x8c0/0x1920
[ 37.398480] ? kasan_check_read+0x11/0x20
[ 37.399235] ? ip_build_and_send_pkt+0xc80/0xc80
[ 37.400096] ? __lock_is_held+0xb6/0x140
[ 37.400836] ? __tcp_v4_send_check+0x1d/0x1d0
[ 37.401672] ? tcp_options_write+0x228/0x940
[ 37.402473] tcp_transmit_skb+0x1b5d/0x3b10
[ 37.403262] ? bictcp_cong_avoid+0xf20/0xf20
[ 37.404060] ? __tcp_select_window+0x920/0x920
[ 37.404902] ? sk_forced_mem_schedule+0x4d/0x160
[ 37.405762] ? sk_stream_alloc_skb+0x33e/0x9b0
[ 37.406595] ? skb_zerocopy_clone+0x5b0/0x5b0
[ 37.407407] ? tcp_init_transfer+0x3f0/0x3f0
[ 37.408206] ? __build_flow_key.constprop.52+0x630/0x630
[ 37.409218] ? tcp_established_options+0x34c/0x5c0
[ 37.410120] ? tcp_rbtree_insert+0x135/0x190
[ 37.410926] ? tcp_fragment+0xad5/0x11a0
[ 37.411679] ? tcp_default_init_rwnd+0x50/0x50
[ 37.412525] ? lock_timer_base+0xaf/0x280
[ 37.413286] ? tcp_trim_head+0x1fb/0x560
[ 37.414029] ? tcp_fragment+0x11a0/0x11a0
[ 37.414794] __tcp_retransmit_skb+0x9a0/0x2b30
[ 37.415632] ? _raw_spin_unlock_irqrestore+0xa6/0xc0
[ 37.416572] ? debug_object_activate+0x307/0x740
[ 37.417439] ? tcp_skb_collapse_tstamp+0x360/0x360
[ 37.418332] ? _raw_spin_unlock_irqrestore+0x31/0xc0
[ 37.419259] ? trace_hardirqs_on_caller+0x19e/0x5c0
[ 37.420169] ? trace_hardirqs_on+0xd/0x10
[ 37.420932] ? mod_timer+0x588/0x13c0
[ 37.421664] ? print_irqtrace_events+0x270/0x270
[ 37.422534] ? tcp_v4_destroy_sock+0x4a3/0x8b0
[ 37.423371] ? print_irqtrace_events+0x270/0x270
[ 37.424238] ? kasan_check_read+0x11/0x20
[ 37.425018] ? refcount_sub_and_test+0x19f/0x280
[ 37.425888] ? refcount_inc_not_zero+0x280/0x280
[ 37.426761] ? del_timer+0xf3/0x140
[ 37.427428] ? tcp_check_oom+0x170/0x590
[ 37.428172] ? tcp_free_fastopen_req+0x90/0x90
[ 37.429013] ? __lock_acquire+0x638/0x3c30
[ 37.429786] ? tcp_skb_mark_lost_uncond_verify+0x16b/0x240
[ 37.430939] ? jiffies_to_msecs+0xd/0x20
[ 37.431698] ? bictcp_state+0x433/0x500
[ 37.432416] ? bictcp_cong_avoid+0xf20/0xf20
[ 37.433265] ? bictcp_cwnd_event+0x120/0x120
[ 37.434058] ? tcp_enter_loss+0xb81/0x10f0
[ 37.434805] tcp_retransmit_skb+0x2e/0x230
[ 37.435571] tcp_retransmit_timer+0xf01/0x2de0
[ 37.436414] ? tcp_delack_timer+0x220/0x220
[ 37.437227] ? __lock_acquire+0x638/0x3c30
[ 37.437990] ? trace_hardirqs_off+0x10/0x10
[ 37.438778] ? debug_check_no_locks_freed+0x3c0/0x3c0
[ 37.439714] ? find_held_lock+0x35/0x1d0
[ 37.440448] ? trace_hardirqs_off+0x10/0x10
[ 37.441237] ? addrconf_rs_timer+0x13b/0x6b0
[ 37.442070] ? pvclock_read_flags+0x160/0x160
[ 37.442888] ? kvm_sched_clock_read+0x25/0x40
[ 37.443699] ? sched_clock+0x31/0x40
[ 37.444373] ? sched_clock_cpu+0x1b/0x180
[ 37.445186] ? lock_release+0xa40/0xa40
[ 37.445936] tcp_write_timer_handler+0x335/0x820
[ 37.446844] ? tcp_retransmit_timer+0x2de0/0x2de0
[ 37.447713] tcp_write_timer+0x153/0x170
[ 37.448425] call_timer_fn+0x22b/0x830
[ 37.449141] ? tcp_write_timer_handler+0x820/0x820
[ 37.450002] ? process_timeout+0x40/0x40
[ 37.450715] ? __run_timers+0x7e5/0xb70
[ 37.451515] ? lock_downgrade+0x980/0x980
[ 37.452275] ? debug_object_deactivate+0x364/0x560
[ 37.453210] ? kasan_check_read+0x11/0x20
[ 37.453963] ? do_raw_spin_trylock+0x1a0/0x1a0
[ 37.454784] ? trace_hardirqs_on_caller+0x19e/0x5c0
[ 37.455662] ? tcp_write_timer_handler+0x820/0x820
[ 37.456580] ? tcp_write_timer_handler+0x820/0x820
[ 37.457479] __run_timers+0x7f0/0xb70
[ 37.458176] ? __bpf_trace_timer_expire_entry+0x30/0x30
[ 37.459148] ? timerqueue_add+0x1e9/0x280
[ 37.459901] ? trace_hardirqs_off+0x10/0x10
[ 37.460694] ? enqueue_hrtimer+0x177/0x4b0
[ 37.461493] ? lock_release+0xa40/0xa40
[ 37.462213] ? hrtimer_update_softirq_timer+0x80/0x80
[ 37.463156] ? rcu_is_watching+0x85/0x130
[ 37.463911] ? account_process_tick+0x8d/0x210
[ 37.464769] ? find_held_lock+0x35/0x1d0
[ 37.465511] ? clockevents_program_event+0x16d/0x2f0
[ 37.466436] ? lock_downgrade+0x980/0x980
[ 37.467192] ? rcu_pm_notify+0xc0/0xc0
[ 37.467901] run_timer_softirq+0x4c/0x70
[ 37.468646] __do_softirq+0x2e0/0xb94
[ 37.469336] ? ktime_get+0x274/0x3b0
[ 37.470016] ? __irqentry_text_end+0x1f9a43/0x1f9a43
[ 37.470944] ? kasan_check_read+0x11/0x20
[ 37.471734] ? do_raw_spin_unlock+0x9e/0x310
[ 37.472553] ? native_apic_msr_write+0x5c/0x80
[ 37.473386] ? __hrtimer_next_event_base+0x1bc/0x260
[ 37.474307] ? lapic_next_event+0x5a/0x90
[ 37.475059] ? clockevents_program_event+0x112/0x2f0
[ 37.475986] ? kasan_check_read+0x11/0x20
[ 37.476744] ? rcu_is_watching+0x85/0x130
[ 37.477499] ? rcu_pm_notify+0xc0/0xc0
[ 37.478210] irq_exit+0x1cc/0x200
[ 37.478840] smp_apic_timer_interrupt+0x175/0x710
[ 37.479718] ? smp_reschedule_interrupt+0xeb/0x660
[ 37.480616] ? smp_call_function_single_interrupt+0x650/0x650
[ 37.481706] ? _raw_spin_lock+0x32/0x40
[ 37.482426] ? _raw_spin_unlock+0x22/0x30
[ 37.483178] ? handle_edge_irq+0x2b9/0x7d0
[ 37.483945] ? rcu_is_watching+0x85/0x130
[ 37.484723] ? task_prio+0x50/0x50
[ 37.485371] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 37.486251] apic_timer_interrupt+0xf/0x20
[ 37.487015] </IRQ>
[ 37.487425] RIP: 0010:_raw_spin_unlock_irq+0x56/0x70
[ 37.488345] Code: cc 86 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48
c1 ea 03 80 3c 02 00 75 1d 48 83 3d 3b 28 1a 01 00 74 11 fb 66 0f 1f
44 00 00 <65> ff 0d 83 43 4f 7a 5b 5d c3 0f 0b e8 19 30 fc fb eb dc 0f
1f 80
[ 37.491897] RSP: 0018:ffff880078b27728 EFLAGS: 00000286 ORIG_RAX:
ffffffffffffff13
[ 37.493310] RAX: dffffc0000000000 RBX: ffff88002dc2cb00 RCX: 0000000000000000
[ 37.494623] RDX: 1ffffffff0d99a4f RSI: 0000000000000001 RDI: ffffffff86ccd278
[ 37.495931] RBP: ffff880078b27730 R08: ffffed0005b85961 R09: 0000000000000000
[ 37.497242] R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff1000f164eee
[ 37.498550] R13: ffff880027918680 R14: 0000000000000000 R15: ffff880078b27810
[ 37.499876] ? _raw_spin_unlock_irq+0x27/0x70
[ 37.500689] finish_task_switch+0x1b9/0x9a0
[ 37.501466] ? finish_task_switch+0x17a/0x9a0
[ 37.502300] ? __switch_to_asm+0x34/0x70
[ 37.503032] ? __switch_to_asm+0x34/0x70
[ 37.503767] ? __switch_to_asm+0x40/0x70
[ 37.504579] ? copy_overflow+0x20/0x20
[ 37.505288] ? __switch_to_asm+0x34/0x70
[ 37.506024] ? __switch_to_asm+0x34/0x70
[ 37.506772] ? __switch_to_asm+0x40/0x70
[ 37.507508] ? __switch_to_asm+0x34/0x70
[ 37.508241] ? __switch_to_asm+0x40/0x70
[ 37.509117] ? __switch_to_asm+0x34/0x70
[ 37.509854] ? __switch_to_asm+0x40/0x70
[ 37.510602] ? __switch_to_asm+0x34/0x70
[ 37.511339] ? __switch_to_asm+0x34/0x70
[ 37.512104] ? __switch_to_asm+0x40/0x70
[ 37.512883] ? __switch_to_asm+0x34/0x70
[ 37.513616] ? __switch_to_asm+0x40/0x70
[ 37.514349] ? __switch_to_asm+0x34/0x70
[ 37.515083] ? __switch_to_asm+0x40/0x70
[ 37.515814] ? __switch_to_asm+0x34/0x70
[ 37.516554] __schedule+0x8fd/0x1ef0
[ 37.517246] ? find_held_lock+0x35/0x1d0
[ 37.517983] ? __sched_text_start+0x8/0x8
[ 37.518732] ? hrtimer_start_range_ns+0x583/0xb90
[ 37.519604] ? lock_downgrade+0x980/0x980
[ 37.520352] ? enqueue_hrtimer+0x177/0x4b0
[ 37.521124] ? kasan_check_read+0x11/0x20
[ 37.521898] ? do_raw_spin_unlock+0x9e/0x310
[ 37.522716] ? do_raw_spin_trylock+0x1a0/0x1a0
[ 37.523549] ? trace_hardirqs_on_caller+0x421/0x5c0
[ 37.524459] ? hrtimer_start_range_ns+0x583/0xb90
[ 37.525347] schedule+0xf5/0x430
[ 37.525961] ? __schedule+0x1ef0/0x1ef0
[ 37.526682] ? debug_object_fixup+0x30/0x30
[ 37.527468] ? find_held_lock+0x35/0x1d0
[ 37.528203] do_nanosleep+0x224/0x6f0
[ 37.528898] ? schedule_timeout_idle+0x90/0x90
[ 37.529732] ? lock_release+0xa40/0xa40
[ 37.530455] ? set_rq_offline.part.85+0x140/0x140
[ 37.531336] ? __wake_up_parent+0x60/0x60
[ 37.532117] ? ktime_get_ts64+0x15f/0x4e0
[ 37.532891] ? memset+0x31/0x40
[ 37.533485] ? __hrtimer_init+0xab/0x1f0
[ 37.534239] hrtimer_nanosleep+0x281/0x4d0
[ 37.535001] ? nanosleep_copyout+0x100/0x100
[ 37.535795] ? clock_was_set_work+0x30/0x30
[ 37.536585] __x64_sys_nanosleep+0x1a8/0x230
[ 37.537383] ? __ia32_compat_sys_nanosleep+0x240/0x240
[ 37.538338] ? do_syscall_64+0x92/0x750
[ 37.539061] do_syscall_64+0x18a/0x750
[ 37.539765] ? syscall_return_slowpath+0x550/0x550
[ 37.540674] ? entry_SYSCALL_64_after_hwframe+0x59/0xbe
[ 37.541643] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 37.542565] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 37.543502] RIP: 0033:0x44c600
[ 37.544076] Code: c0 5b 5d c3 66 0f 1f 44 00 00 8b 04 24 48 83 c4
18 5b 5d c3 66 0f 1f 44 00 00 83 3d e9 0b 28 00 00 75 14 b8 23 00 00
00 0f 05 <48> 3d 01 f0 ff ff 0f 83 84 15 fc ff c3 48 83 ec 08 e8 0a 2c
00 00
[ 37.547594] RSP: 002b:00007ffe719a7178 EFLAGS: 00000246 ORIG_RAX:
0000000000000023
[ 37.548978] RAX: ffffffffffffffda RBX: 00000000004002f8 RCX: 000000000044c600
[ 37.550298] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007ffe719a7180
[ 37.551609] RBP: 00007ffe719a7330 R08: 0000000001696940 R09: 0000000000000005
[ 37.552966] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000040df30
[ 37.554274] R13: 000000000040dfc0 R14: 0000000000000000 R15: 0000000000000000
[ 37.555588] Modules linked in:
[ 37.556288] ---[ end trace 3660ab58ce89576b ]---

[ 37.557277] RIP: 0010:skb_copy_and_csum_bits+0x5e4/0x6e0
[ 37.558283] Code: 49 63 c4 48 01 45 c8 01 45 b8 41 01 c5 e9 1d ff
ff ff 8b 5d d4 e8 0c 9f 26 fd 8b 45 c0 85 c0 0f 84 ab fe ff ff e8 fc
9e 26 fd <0f> 0b 45 31 ff e9 4c fb ff ff 8b 5d d4 e9 94 fe ff ff e8 e5
9e 26
[ 37.561863] RSP: 0018:ffff88002dc06220 EFLAGS: 00010206
[ 37.563126] RAX: ffff88007a46a640 RBX: 000000006485bc1a RCX: ffffffff844d49f4
[ 37.564525] RDX: 0000000000000100 RSI: ffff88002a1765cc RDI: ffff88002a1a4308
[ 37.565845] RBP: ffff88002dc062a0 R08: 0000000000000000 R09: 0000000000000000
[ 37.567182] R10: 000000000000003c R11: ffffed0005b80bef R12: ffff880029b2e068
[ 37.568496] R13: ffff88002132f980 R14: 00000000000001e8 R15: 000000000000003c
[ 37.569813] FS: 0000000001696940(0000) GS:ffff88002dc00000(0000)
knlGS:0000000000000000
[ 37.571323] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 37.572474] CR2: 00007f8c46d84db8 CR3: 000000007df16000 CR4: 00000000000006f0
[ 37.573848] Kernel panic - not syncing: Fatal exception in interrupt
[ 37.575321] Kernel Offset: disabled
[ 37.575970] Rebooting in 86400 seconds..

[L. Alberto Giménez]

On Thu, Jun 07, 2018 at 08:37:08PM +0200, Dmitry Vyukov wrote:
> On Tue, Jun 5, 2018 at 3:45 PM, L. Alberto Giménez <agim...@sysvalve.es> wrote:
> >> > I'm kind of "triaging"/checking if I can reproduce some of the bugs, but I
> >> > can't reproduce this particular one in a qemu VM.
> >> >
> >> > I compiled a kernel from commit 786b71f5b754273ccef6d9462e52062b3e1f9877
> >> > "Merge tag 'nds32-for-linus-4.17-fixes' of
> >> > git://git.kernel.org/pub/scm/linux/kernel/git/greentime/linux" but I got
> >> > this output from the C repro:
> >>
> >> Hi,
> >>
> >> Did you use the provided config? Most of the devices referenced as
> >> "Cannot find device" must be present with the config.
> >>
> >
> > Hi,
> >
> > I checked again, checked ouy from the last commit registered in the bug page
> > (https://syzkaller.appspot.com/bug?id=9c55af67ce995cf6c4f11ab6f5d3ee805d67fc00). The
> > commit is 13405468f49d4b6e014fdf376f46393f9590769d "bpf ilter: don't pass O_CREAT when opening console for debug"
>

> I was able to trigger the BUG within a second in qemu.
> I took exactly the provided commit
> (f9f1e414128ea58d8e848a0275db0f644c9e9f45), the provided config and my
> host gcc 7.3. You can take gcc 7 and image here:
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce
>

Regarding the "workflow", I would like to have something clear here. I see you
used a commit from upstream that is not the last in the list (see
https://syzkaller.appspot.com/bug?id=9c55af67ce995cf6c4f11ab6f5d3ee805d67fc00). I
always try to test the latest reported commit with a C repro. In this case is
13405468f49d4b6e014fdf376f46393f9590769d, the one I tested without luck.

So, if the latest failing entry (May 24, commit 13405468f49d4b6e014, from net-next) is not
reproduceable, what should I do? My guess is consider it fixed, but I can see you
kept digging until you were able to reproduce it. Is that what we should do?

Thanks,

[L. Alberto Giménez]

On Thu, Jun 07, 2018 at 08:59:10PM +0200, Dmitry Vyukov wrote:
> On Thu, Jun 7, 2018 at 8:37 PM, Dmitry Vyukov <dvy...@google.com> wrote:
> > On Tue, Jun 5, 2018 at 3:45 PM, L. Alberto Giménez <agim...@sysvalve.es> wrote:
> >>> > I'm kind of "triaging"/checking if I can reproduce some of the bugs, but I
> >>> > can't reproduce this particular one in a qemu VM.
> >>> >
> >>> > I compiled a kernel from commit 786b71f5b754273ccef6d9462e52062b3e1f9877
> >>> > "Merge tag 'nds32-for-linus-4.17-fixes' of
> >>> > git://git.kernel.org/pub/scm/linux/kernel/git/greentime/linux" but I got
> >>> > this output from the C repro:
> >>>
> >>> Hi,
> >>>
> >>> Did you use the provided config? Most of the devices referenced as
> >>> "Cannot find device" must be present with the config.
> >>>
> >>
> >> Hi,
> >>
> >> I checked again, checked ouy from the last commit registered in the bug page
> >> (https://syzkaller.appspot.com/bug?id=9c55af67ce995cf6c4f11ab6f5d3ee805d67fc00). The
> >> commit is 13405468f49d4b6e014fdf376f46393f9590769d "bpf ilter: don't pass O_CREAT when opening console for debug"
> >>
> >> I double-checked the config file, made olddefconfig from that config, and ran the
> >> reproducer in a KVM virtual machine with that kernel installed. No BUG whatsoever,
> >> but got multiple repeated messages instead from the reproducer:
>

> This exact reproducer does not trigger the crash on latest upstream for me.
> However, syzbot claims this still happens:
> https://syzkaller.appspot.com/bug?id=9c55af67ce995cf6c4f11ab6f5d3ee805d67fc00
>
> The reproducer from May 24 triggered the crash on the latest upstream
> (c90fca951e90ba470a3dc6087667edffcf8db21b) for me.
> Maybe it's a different bug, and the old one was either fixed or
> requires a different reproducer now...

So, what should we do now? Mark this one as fixed, or at least tell syzbot to retry
with latest upstream?

In general, should we just test the latest upstream against the lastest reproducer?
Is that a way to test if the bug doesn't show anymore? Testing against "past commits"
doesn't seem meaningful to me, since the latest code could have fixed already the
bug.

Maybe the way the fuzzers work is tied to a particular commit and even the bug
not showing in the latest commit is just because it remains hidden, so we really
need to address that issue even when it does not show up in latter commits?

I'll try to reproduce with latest upstream and the May 24 reproducer.

Thanks,

[Dmitry Vyukov]

On Fri, Jun 8, 2018 at 10:18 AM, L. Alberto Giménez

I did not know which one you tested, so I took the one from email first.

> So, if the latest failing entry (May 24, commit 13405468f49d4b6e014, from net-next) is not
> reproduceable, what should I do? My guess is consider it fixed, but I can see you
> kept digging until you were able to reproduce it. Is that what we should do?

Is it easily reproducible for me, see the previous message:
https://groups.google.com/d/msg/syzkaller-bugs/OMtPtsi6N7A/iQt-DSMlBQAJ

Did you take the exact commit/config? Not sure if it requires exact
compiler, most likely not. What do you use for image and machine?

[Dmitry Vyukov]

On Fri, Jun 8, 2018 at 10:25 AM, L. Alberto Giménez

These all are reproducible, so I would say: debug the root cause(s)
and then act based on the results.
There seems to be at least one bug that still happens on latest
upstream. Potentially there was another bug (that would explain why
the older reproducer does not work on latest upstream), and it was
either fixed, or masked by something else.

[syzbot]

syzbot has bisected this bug to:

commit 84e54fe0a5eaed696dee4019c396f8396f5a908b
Author: William Tu <u901...@gmail.com>

Date: Tue Aug 22 16:40:28 2017 +0000

gre: introduce native tunnel support for ERSPAN

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=158a2f86e00000
start commit: f9f1e414 Merge tag 'for-linus-4.16-rc1-tag' of git://git.k..
git tree: upstream
final crash: https://syzkaller.appspot.com/x/report.txt?x=178a2f86e00000
console output: https://syzkaller.appspot.com/x/log.txt?x=138a2f86e00000
kernel config: https://syzkaller.appspot.com/x/.config?x=34a80ee1ac29767b
dashboard link: https://syzkaller.appspot.com/bug?extid=b2bf2652983d23734c5c
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=147bfebd800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13d8d543800000

Reported-by: syzbot+b2bf26...@syzkaller.appspotmail.com
Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

[Dmitry Vyukov]

Humm... the repro contains syz_emit_ethernet, wonder if it's
remote-triggerable...

[Marcelo Ricardo Leitner]

The call trace is still from the tx path. Packet never left the system
in this case.

[Dmitry Vyukov]

My understanding is that this does not necessarily mean that the
remote side is not involved. There is enough state on the host for L4
protocols, so that the remote side can mess things and then the bad
thing will happen with local trigger. But that local trigger can be
just anything trivial that everybody does.

[Neil Horman]

But thats not really helpful. Unless you see an explicit path from the receive
side to ip6_append_data, Theres no real way for a received packet to reach this
code, so we can't really call it remotely triggerable.

My guess is, since this is coming from the rawv6_sendmsg path, that the raw
protocol is somehow not marshaling its data in a way that ip6_append_data
expects.

Neil

[Dmitry Vyukov]

If it's in the local send path and does not use any remotely
controllable data, then this should be good enough estimation of not
being a remote attack vector.