On Tue, Dec 3, 2019 at 12:56 PM Neil Horman <nhorman@xxxxxxxxxxxxx> 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 > > <marcelo.leitner@xxxxxxxxx> wrote: > > > > > > On Sat, Nov 30, 2019 at 04:37:56PM +0100, Dmitry Vyukov wrote: > > > > On Sat, Nov 30, 2019 at 3:50 PM syzbot > > > > <syzbot+b2bf2652983d23734c5c@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > > syzbot has bisected this bug to: > > > > > > > > > > commit 84e54fe0a5eaed696dee4019c396f8396f5a908b > > > > > Author: William Tu <u9012063@xxxxxxxxx> > > > > > 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@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > > 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.
