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: <20190320053532.o7hawr2vkj6fxbv7@gondor.apana.org.au>
Date:   Wed, 20 Mar 2019 13:35:32 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Cong Wang <xiyou.wangcong@...il.com>
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 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.

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.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt