Re: general protection fault in skb_put

[James Smart]

On 3/11/2019 9:40 AM, Dmitry Vyukov wrote:
> On Mon, Mar 11, 2019 at 5:20 PM 'James Smart' via syzkaller-bugs
> <syzkaller-bugs@xxxxxxxxxxxxxxxx> wrote:
> > On 3/11/2019 6:20 AM, syzbot wrote:
> > > syzbot has bisected this bug to:
> > >
> > > commit 97faec531460c949d7120672b8c77e2f41f8d6d7
> > > Author: James Smart <jsmart2021@xxxxxxxxx>
> > > Date:   Thu Sep 13 23:17:38 2018 +0000
> > >
> > >      nvme_fc: add 'nvme_discovery' sysfs attribute to fc transport device
> > >
> > > bisection log:
> > > https://syzkaller.appspot.com/x/bisect.txt?x=121f55db200000
> > > start commit:   97faec53 nvme_fc: add 'nvme_discovery' sysfs attribute
> > > to ..
> > > git tree:       linux-next
> > > final crash: https://syzkaller.appspot.com/x/report.txt?x=111f55db200000
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=161f55db200000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=59aefae07c771af6
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=65788f9af9d54844389e
> > > userspace arch: amd64
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=178e0798c00000
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11b4f0b0c00000
> > >
> > > Reported-by: syzbot+65788f9af9d54844389e@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > Fixes: 97faec53 ("nvme_fc: add 'nvme_discovery' sysfs attribute to fc
> > > transport device")
> >
> > can someone contact me as to what this thing is doing and how to
> > interpret all the logs.  nvme_fc isn't remotely in any of the logs and
> > doesn't use skb's unless the underlying udev_uevents are using them.
>
> Hi James,
>
> What exactly is unclear/needs interpretation? syzbot did what is
> commonly known as kernel/git bisection process. This is a new feature
> so there can be some rough edges. Hopefully we can improve the
> representation together.
>
> Thanks
Everything is unclear. You're telling me that an error occurred and that 
you reduced it to the git submit where the error starts appearing.

Usually there would be something in the base crash, which I'm looking at 
in https://syzkaller.appspot.com/x/report.txt?x=111f55db200000 which 
would point back at something in the patch or related to it. There are 
no relationships.  I can't quite figure out what the base test actually 
did that generated the failure to see if there's any possible relationship.

Everything in the base crash stacktrace points to an issue in the 
bluetooth uart driver doing all the logging - not the patch called out. 
So this looks like a failure of your infrastructure.

-- james