1. 19 Dec, 2017 1 commit
  2. 12 Dec, 2017 1 commit
  3. 08 Dec, 2017 2 commits
    • Steffen Klassert's avatar
      xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies. · 732706af
      Steffen Klassert authored
      On policies with a transport mode template, we pass the addresses
      from the flowi to xfrm_state_find(), assuming that the IP addresses
      (and address family) don't change during transformation.
      
      Unfortunately our policy template validation is not strict enough.
      It is possible to configure policies with transport mode template
      where the address family of the template does not match the selectors
      address family. This lead to stack-out-of-bound reads because
      we compare arddesses of the wrong family. Fix this by refusing
      such a configuration, address family can not change on transport
      mode.
      
      We use the assumption that, on transport mode, the first templates
      address family must match the address family of the policy selector.
      Subsequent transport mode templates must mach the address family of
      the previous template.
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      732706af
    • Antony Antony's avatar
      xfrm: fix xfrm_do_migrate() with AEAD e.g(AES-GCM) · 75bf50f4
      Antony Antony authored
      copy geniv when cloning the xfrm state.
      
      x->geniv was not copied to the new state and migration would fail.
      
      xfrm_do_migrate
        ..
        xfrm_state_clone()
         ..
         ..
         esp_init_aead()
         crypto_alloc_aead()
          crypto_alloc_tfm()
           crypto_find_alg() return EAGAIN and failed
      Signed-off-by: default avatarAntony Antony <antony@phenome.org>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      75bf50f4
  4. 01 Dec, 2017 3 commits
  5. 29 Nov, 2017 1 commit
    • Cong Wang's avatar
      xfrm: check id proto in validate_tmpl() · 6a53b759
      Cong Wang authored
      syzbot reported a kernel warning in xfrm_state_fini(), which
      indicates that we have entries left in the list
      net->xfrm.state_all whose proto is zero. And
      xfrm_id_proto_match() doesn't consider them as a match with
      IPSEC_PROTO_ANY in this case.
      
      Proto with value 0 is probably not a valid value, at least
      verify_newsa_info() doesn't consider it valid either.
      
      This patch fixes it by checking the proto value in
      validate_tmpl() and rejecting invalid ones, like what iproute2
      does in xfrm_xfrmproto_getbyname().
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      6a53b759
  6. 28 Nov, 2017 31 commits
  7. 27 Nov, 2017 1 commit