netdev - Re: pull request (net): ipsec 2018-10-01

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:   Mon, 01 Oct 2018 22:29:45 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     steffen.klassert@...unet.com
Cc:     herbert@...dor.apana.org.au, netdev@...r.kernel.org
Subject: Re: pull request (net): ipsec 2018-10-01

From: Steffen Klassert <steffen.klassert@...unet.com>
Date: Mon, 1 Oct 2018 10:58:49 +0200

> 1) Validate address prefix lengths in the xfrm selector,
>    otherwise we may hit undefined behaviour in the
>    address matching functions if the prefix is too
>    big for the given address family.
> 
> 2) Fix skb leak on local message size errors.
>    From Thadeu Lima de Souza Cascardo.
> 
> 3) We currently reset the transport header back to the network
>    header after a transport mode transformation is applied. This
>    leads to an incorrect transport header when multiple transport
>    mode transformations are applied. Reset the transport header
>    only after all transformations are already applied to fix this.
>    From Sowmini Varadhan.
> 
> 4) We only support one offloaded xfrm, so reset crypto_done after
>    the first transformation in xfrm_input(). Otherwise we may call
>    the wrong input method for subsequent transformations.
>    From Sowmini Varadhan.
> 
> 5) Fix NULL pointer dereference when skb_dst_force clears the dst_entry.
>    skb_dst_force does not really force a dst refcount anymore, it might
>    clear it instead. xfrm code did not expect this, add a check to not
>    dereference skb_dst() if it was cleared by skb_dst_force.
> 
> 6) Validate xfrm template mode, otherwise we can get a stack-out-of-bounds
>    read in xfrm_state_find. From Sean Tranchetti.
> 
> Please pull or let me know if there are problems.

Pulled, thanks!