Re: general protection fault in __xfrm_policy_bysel_ctx

[Dmitry Vyukov]

On Wed, Jan 30, 2019 at 3:30 PM Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
>
> 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.

Thanks for cleaning it all up!

(Florian updated 17 other bugs)