Re: general protection fault in __xfrm_policy_bysel_ctx

[Dmitry Vyukov]

On Wed, Jan 30, 2019 at 3:20 PM Florian Westphal <fw@xxxxxxxxx> wrote:
>
> Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
> > > syzbot <syzbot+e6e1fe9148cffa18cf97@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > > > Hello,
> > > >
> > > > syzbot found the following crash on:
> > > >
> > > > HEAD commit:    085c4c7dd2b6 net: lmc: remove -I. header search path
> > > > git tree:       net-next
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=12347128c00000
> > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=505743eba4e4f68
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=e6e1fe9148cffa18cf97
> > > > compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> > > >
> > > > Unfortunately, I don't have any reproducer for this crash yet.
> > >
> > > net-next doesn't contain the fixes for the rbtree fallout yet, so
> > > this might already be fixed (fingers crossed).
> >
> > Hi Florian,
> >
> > What is that fix for the record?
>
> I don't know.  I managed to add every bug class imagineable in that series 8-(
>
> The last (most recent) fix from the 'fallout cleanup' is:
> 12750abad517a991c4568969bc748db302ab52cd
> ("xfrm: policy: fix infinite loop when merging src-nodes")
>
> so if syzkaller can generate a splat with that change present
> something is still broken.
>
> > We will need to close this later. Or perhaps we can already mark this
> > as fixed by that patch with "#syz fix:" command?
>
> There are a lot of open xfrm related splats that could all be explained
> by the rbtree bugs (one had a reproducer, the fix has appropriate
> reported-by tag).
>
> It would be great if there was a way to tell syzkaller to report those
> again if they still appear.

That's exactly what "#syz fix:" will do.
syzbot will wait until the fixing commit appears in all builds/trees
it tests, then close this bug, and then any new similarly looking
crash will produce a new bug report. So if the patch indeed fixes the
bug, then the bug will be closed and we are done. If it does not fix
this bug, then we will get another report but at that time on a tree
that includes the commit.

> I could pretend and claim above commit as "sys-fix", but it seems fishy.
>
> Let me know and I can tag all of them.

It's "safe" to mark these crashes as fixed when we are not 100% sure
in the sense that we won't lose the bug (it will be reported again
later if it's not fixed).
It's also useful to keep the list of open/active bugs shorter and more
precise (don't leave too many obsoleted open bugs). What happened
multiple times is that a bug was fixed but left open, and then a
similarly looking crashes started happening again (a new bug), but it
wasn't reported by syzbot because for syzbot it looked like the old
still unfixed bug.