2018-02-10 05:26:37

by syzbot

[permalink] [raw]
Subject: kernel BUG at net/core/skbuff.c:LINE! (3)

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: [email protected]
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 ]---


Attachments:
raw.log.txt (7.79 kB)
repro.syz.txt (9.35 kB)
repro.c.txt (32.35 kB)
config.txt (133.19 kB)
Download all attachments

2018-02-10 11:18:47

by Xin Long

[permalink] [raw]
Subject: Re: kernel BUG at net/core/skbuff.c:LINE! (3)

On Fri, Feb 2, 2018 at 3:21 AM, syzbot
<[email protected]> 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: [email protected]
> 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.

> ------------[ 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 [email protected].
>
> 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.

2018-05-10 09:53:03

by Dmitry Vyukov

[permalink] [raw]
Subject: Re: kernel BUG at net/core/skbuff.c:LINE! (3)

On Sat, Feb 10, 2018 at 12:17 PM, Xin Long <[email protected]> wrote:
> On Fri, Feb 2, 2018 at 3:21 AM, syzbot
> <[email protected]> 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: [email protected]
>> 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 <[email protected]>
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




>> ------------[ 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 [email protected].
>>
>> 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.

2019-11-30 14:53:02

by syzbot

[permalink] [raw]
Subject: Re: kernel BUG at net/core/skbuff.c:LINE! (3)

syzbot has bisected this bug to:

commit 84e54fe0a5eaed696dee4019c396f8396f5a908b
Author: William Tu <[email protected]>
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: [email protected]
Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")

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

2019-11-30 15:40:29

by Dmitry Vyukov

[permalink] [raw]
Subject: Re: kernel BUG at net/core/skbuff.c:LINE! (3)

On Sat, Nov 30, 2019 at 3:50 PM syzbot
<[email protected]> wrote:
>
> syzbot has bisected this bug to:
>
> commit 84e54fe0a5eaed696dee4019c396f8396f5a908b
> Author: William Tu <[email protected]>
> 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: [email protected]
> Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection

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

2019-12-02 20:25:53

by Marcelo Ricardo Leitner

[permalink] [raw]
Subject: Re: kernel BUG at net/core/skbuff.c:LINE! (3)

On Sat, Nov 30, 2019 at 04:37:56PM +0100, Dmitry Vyukov wrote:
> On Sat, Nov 30, 2019 at 3:50 PM syzbot
> <[email protected]> wrote:
> >
> > syzbot has bisected this bug to:
> >
> > commit 84e54fe0a5eaed696dee4019c396f8396f5a908b
> > Author: William Tu <[email protected]>
> > 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: [email protected]
> > Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
> Humm... the repro contains syz_emit_ethernet, wonder if it's
> remote-triggerable...

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

2019-12-03 08:43:16

by Dmitry Vyukov

[permalink] [raw]
Subject: Re: kernel BUG at net/core/skbuff.c:LINE! (3)

On Mon, Dec 2, 2019 at 7:39 PM Marcelo Ricardo Leitner
<[email protected]> wrote:
>
> On Sat, Nov 30, 2019 at 04:37:56PM +0100, Dmitry Vyukov wrote:
> > On Sat, Nov 30, 2019 at 3:50 PM syzbot
> > <[email protected]> wrote:
> > >
> > > syzbot has bisected this bug to:
> > >
> > > commit 84e54fe0a5eaed696dee4019c396f8396f5a908b
> > > Author: William Tu <[email protected]>
> > > 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: [email protected]
> > > Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
> > >
> > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> >
> > Humm... the repro contains syz_emit_ethernet, wonder if it's
> > remote-triggerable...
>
> The call trace is still from the tx path. Packet never left the system
> in this case.

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.

2019-12-03 11:57:22

by Neil Horman

[permalink] [raw]
Subject: Re: kernel BUG at net/core/skbuff.c:LINE! (3)

On Tue, Dec 03, 2019 at 09:42:14AM +0100, Dmitry Vyukov wrote:
> On Mon, Dec 2, 2019 at 7:39 PM Marcelo Ricardo Leitner
> <[email protected]> wrote:
> >
> > On Sat, Nov 30, 2019 at 04:37:56PM +0100, Dmitry Vyukov wrote:
> > > On Sat, Nov 30, 2019 at 3:50 PM syzbot
> > > <[email protected]> wrote:
> > > >
> > > > syzbot has bisected this bug to:
> > > >
> > > > commit 84e54fe0a5eaed696dee4019c396f8396f5a908b
> > > > Author: William Tu <[email protected]>
> > > > 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: [email protected]
> > > > Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
> > > >
> > > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> > >
> > > Humm... the repro contains syz_emit_ethernet, wonder if it's
> > > remote-triggerable...
> >
> > The call trace is still from the tx path. Packet never left the system
> > in this case.
>
> 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.
>
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

2019-12-04 08:54:00

by Dmitry Vyukov

[permalink] [raw]
Subject: Re: kernel BUG at net/core/skbuff.c:LINE! (3)

On Tue, Dec 3, 2019 at 12:56 PM Neil Horman <[email protected]> wrote:
>
> On Tue, Dec 03, 2019 at 09:42:14AM +0100, Dmitry Vyukov wrote:
> > On Mon, Dec 2, 2019 at 7:39 PM Marcelo Ricardo Leitner
> > <[email protected]> wrote:
> > >
> > > On Sat, Nov 30, 2019 at 04:37:56PM +0100, Dmitry Vyukov wrote:
> > > > On Sat, Nov 30, 2019 at 3:50 PM syzbot
> > > > <[email protected]> wrote:
> > > > >
> > > > > syzbot has bisected this bug to:
> > > > >
> > > > > commit 84e54fe0a5eaed696dee4019c396f8396f5a908b
> > > > > Author: William Tu <[email protected]>
> > > > > 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: [email protected]
> > > > > Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
> > > > >
> > > > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> > > >
> > > > Humm... the repro contains syz_emit_ethernet, wonder if it's
> > > > remote-triggerable...
> > >
> > > The call trace is still from the tx path. Packet never left the system
> > > in this case.
> >
> > 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.
> >
> 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.

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.