netdev - Re: [Patch net] xfrm: unify xfrm protocol checks

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAM_iQpU=3nw6WsJ7pb+P3H2sObhbgjcPHRqJcArOPNMPx+n65A@mail.gmail.com>
Date:   Thu, 21 Mar 2019 21:06:05 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Herbert Xu <herbert@...dor.apana.org.au>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        syzbot+0bf0519d6e0de15914fe@...kaller.appspotmail.com,
        Steffen Klassert <steffen.klassert@...unet.com>
Subject: Re: [Patch net] xfrm: unify xfrm protocol checks

On Tue, Mar 19, 2019 at 10:35 PM Herbert Xu <herbert@...dor.apana.org.au> wrote:
>
> On Tue, Mar 19, 2019 at 01:42:53PM -0700, Cong Wang wrote:
> >
> > IIRC, it is Steffen who suggested to add IPPROTO_ROUTING/IPPROTO_DSTOPTS
> > back to commit 6a53b7593233. My xfrm knowledge is not enough to
> > figure out IPPROTO_ROUTING/IPPROTO_DSTOPTS.
>
> OK I dug into the history of xfrm_id_proto_match and this is
> definitely not right.  The intention appears to be that
> IPSEC_PROTO_ANY should only match genuine IPsec protocols, i.e.,
> AH/ESP/COMP, while the special value of zero will match everything.
>
> So I think what we should do is get rid of the validation function
> that you added in 6a5t3b7593233, and then change those internal
> functions which were incorrectly using IPSEC_PROTO_ANY to using
> zero instead.

Good point. Replacing IPSEC_PROTO_ANY with zero should
work too, but on the other hand, id.proto is still never allowed to
be any other protocol than these 6 listed, no?


>
> Does anybody still use IPPROTO_ROUTING/IPPROTO_DSTOPTS? It's always
> a pain when people come and add features and then don't shoulder
> the burden of maintaining them.

Yeah, at least iproute2 does the same check:

static const struct typeent xfrmproto_types[] = {
        { "esp", IPPROTO_ESP }, { "ah", IPPROTO_AH }, { "comp", IPPROTO_COMP },
        { "route2", IPPROTO_ROUTING }, { "hao", IPPROTO_DSTOPTS },
        { "ipsec-any", IPSEC_PROTO_ANY },
        { NULL, -1 }
};