netdev - Re: [PATCH v2] xfrm: Return error on unknown encap_type in init

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] [day] [month] [year] [list]

Date:   Tue, 9 Jan 2018 12:59:29 +0100
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Herbert Xu <herbert@...dor.apana.org.au>
CC:     <netdev@...r.kernel.org>
Subject: Re: [PATCH v2] xfrm: Return error on unknown encap_type in init_state

On Fri, Jan 05, 2018 at 10:12:32PM +1100, Herbert Xu wrote:
> On Fri, Jan 05, 2018 at 09:32:47AM +0100, Steffen Klassert wrote:
> >
> > Looks like we catch the unknown mode in __xfrm_init_state().
> > But in any case, if we want to return -EINVAL on unknown mode,
> > we should do it for IPv6 and for IPv4.
> 
> OK, how about this one then:
> 
> ---8<---
> Currently esp will happily create an xfrm state with an unknown
> encap type for IPv4, without setting the necessary state parameters.
> This patch fixes it by returning -EINVAL.
> 
> There is a similar problem in IPv6 where if the mode is unknown
> we will skip initialisation while returning zero.  However, this
> is harmless as the mode has already been checked further up the
> stack.  This patch removes this anomaly by aligning the IPv6
> behaviour with IPv4 and treating unknown modes (which cannot
> actually happen) as transport mode.
> 
> Fixes: 38320c70d282 ("[IPSEC]: Use crypto_aead and authenc in ESP")
> Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>

Patch applied, thanks Herbert!