On Mon, Jun 18, 2018 at 6:14 AM, Jason Litzinger
<[email protected]> wrote:
> I've simplified the reproducer provided by syzbot to the included
> version. The warning is reproduced 100% using the qemu image in the
> syzkaller docs running the latest upstream and net.
>
> As noted on the dashboard, this is similar to [1], in that an entry
> remains in the xfrm_state_walk list, but different because the
> protocol is not 0, it is 43, IPPROTO_ROUTING (and is valid by the fix
> for [1], see 6a53b7593233).
>
> Unfortunately, when a namespace exits, xfrm_state_fini only flushes
> IPSEC protocols. I don't have enough experience with the xfrm
> subsystem to know whether this is correct, however, dc00a525603650a14
> explicitly allows non ipsec protocols, as well as 0 for "all".
>
> Would it be more appropriate for flush to also flush the non ipsec
> protocols allowed in xfrm_user.c:validate_tmpl (explicitly or with 0)?
>
> If someone with more experience with the subsystem believes that to be
> the case I'm happy to send a patch (against net or ipsec?), otherwise
> I'm going to keep digging to see if a better option presents itself.
>
> Regardless I hope the simplified reproducer might be useful.
>
> -Jason
>
> [1]
> https://syzkaller.appspot.com/bug?id=c922592229951800c197ce48a5eaab8877c33723
>
> * I wasn't subscribed to the list for the original message, so I'm
> using the GUI to reply...apologies if anything is mangled.
+kernel developers back to CC
Jason did some debugging of this bug and have some questions as to
what's the best way to proceed. Please read the above.
On Mon, Jun 18, 2018 at 09:25:31AM +0200, Dmitry Vyukov wrote:
> On Mon, Jun 18, 2018 at 6:14 AM, Jason Litzinger
> <[email protected]> wrote:
> > I've simplified the reproducer provided by syzbot to the included
> > version. The warning is reproduced 100% using the qemu image in the
> > syzkaller docs running the latest upstream and net.
> >
> > As noted on the dashboard, this is similar to [1], in that an entry
> > remains in the xfrm_state_walk list, but different because the
> > protocol is not 0, it is 43, IPPROTO_ROUTING (and is valid by the fix
> > for [1], see 6a53b7593233).
> >
> > Unfortunately, when a namespace exits, xfrm_state_fini only flushes
> > IPSEC protocols. I don't have enough experience with the xfrm
> > subsystem to know whether this is correct, however, dc00a525603650a14
> > explicitly allows non ipsec protocols, as well as 0 for "all".
> >
> > Would it be more appropriate for flush to also flush the non ipsec
> > protocols allowed in xfrm_user.c:validate_tmpl (explicitly or with 0)?
> >
> > If someone with more experience with the subsystem believes that to be
> > the case I'm happy to send a patch (against net or ipsec?), otherwise
> > I'm going to keep digging to see if a better option presents itself.
> >
> > Regardless I hope the simplified reproducer might be useful.
> >
> > -Jason
> >
> > [1]
> > https://syzkaller.appspot.com/bug?id=c922592229951800c197ce48a5eaab8877c33723
> >
> > * I wasn't subscribed to the list for the original message, so I'm
> > using the GUI to reply...apologies if anything is mangled.
>
> +kernel developers back to CC
Thanks for the info!
I'm traveling currently, so it may take some time
until I can look at it.