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

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.

Thanks!

The following changes since commit 25432eba9cd8f2ef5afef55be811b010a004b5fa:

  openvswitch: meter: Fix setting meter id for new entries (2018-07-29 13:20:54 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec.git master

for you to fetch changes up to 32bf94fb5c2ec4ec842152d0e5937cd4bb6738fa:

  xfrm: validate template mode (2018-09-20 08:30:42 +0200)

----------------------------------------------------------------
Sean Tranchetti (1):
      xfrm: validate template mode

Sowmini Varadhan (2):
      xfrm: reset transport header back to network header after all input transforms ahave been applied
      xfrm: reset crypto_done when iterating over multiple input xfrms

Steffen Klassert (2):
      xfrm: Validate address prefix lengths in the xfrm selector.
      xfrm: Fix NULL pointer dereference when skb_dst_force clears the dst_entry.

Thadeu Lima de Souza Cascardo (1):
      xfrm6: call kfree_skb when skb is toobig

 net/ipv4/xfrm4_input.c          |  1 +
 net/ipv4/xfrm4_mode_transport.c |  4 +---
 net/ipv6/xfrm6_input.c          |  1 +
 net/ipv6/xfrm6_mode_transport.c |  4 +---
 net/ipv6/xfrm6_output.c         |  2 ++
 net/xfrm/xfrm_input.c           |  1 +
 net/xfrm/xfrm_output.c          |  4 ++++
 net/xfrm/xfrm_policy.c          |  4 ++++
 net/xfrm/xfrm_user.c            | 15 +++++++++++++++
 9 files changed, 30 insertions(+), 6 deletions(-)

From: Steffen Klassert <steffen.klassert@secunet.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!