netdev - Re: WARNING in xfrm_state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 18 Jun 2018 09:25:31 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Jason Litzinger <jlitzingerdev@...il.com>,
        David Miller <davem@...emloft.net>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        LKML <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        Steffen Klassert <steffen.klassert@...unet.com>
Cc:     syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: WARNING in xfrm_state_fini (2)

On Mon, Jun 18, 2018 at 6:14 AM, Jason Litzinger
<jlitzingerdev@...il.com> 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.