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
[off-list ref] wrote:

quoted

On Sat, Nov 30, 2019 at 04:37:56PM +0100, Dmitry Vyukov wrote:

quoted

On Sat, Nov 30, 2019 at 3:50 PM syzbot
[off-list ref] wrote:

quoted

syzbot has bisected this bug to:

commit 84e54fe0a5eaed696dee4019c396f8396f5a908b
Author: William Tu [off-list ref]
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+b2bf2652983d23734c5c@syzkaller.appspotmail.com
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