1. 30 Jan, 2017 2 commits
  2. 17 Jan, 2017 3 commits
  3. 16 Jan, 2017 3 commits
    • Gilad Ben-Yossef's avatar
      IPsec: do not ignore crypto err in ah6 input · 726282aa
      Gilad Ben-Yossef authored
      ah6 input processing uses the asynchronous hash crypto API which
      supplies an error code as part of the operation completion but
      the error code was being ignored.
      
      Treat a crypto API error indication as a verification failure.
      
      While a crypto API reported error would almost certainly result
      in a memcpy of the digest failing anyway and thus the security
      risk seems minor, performing a memory compare on what might be
      uninitialized memory is wrong.
      Signed-off-by: default avatarGilad Ben-Yossef <gilad@benyossef.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      726282aa
    • Gilad Ben-Yossef's avatar
      IPsec: do not ignore crypto err in ah4 input · ebd89a2d
      Gilad Ben-Yossef authored
      ah4 input processing uses the asynchronous hash crypto API which
      supplies an error code as part of the operation completion but
      the error code was being ignored.
      
      Treat a crypto API error indication as a verification failure.
      
      While a crypto API reported error would almost certainly result
      in a memcpy of the digest failing anyway and thus the security
      risk seems minor, performing a memory compare on what might be
      uninitialized memory is wrong.
      Signed-off-by: default avatarGilad Ben-Yossef <gilad@benyossef.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      ebd89a2d
    • Florian Westphal's avatar
      xfrm: fix possible null deref in xfrm_init_tempstate · 3819a35f
      Florian Westphal authored
      Dan reports following smatch warning:
       net/xfrm/xfrm_state.c:659
       error: we previously assumed 'afinfo' could be null (see line 651)
      
       649  struct xfrm_state_afinfo *afinfo = xfrm_state_afinfo_get_rcu(family);
       651  if (afinfo)
      		...
       658  }
       659  afinfo->init_temprop(x, tmpl, daddr, saddr);
      
      I am resonably sure afinfo cannot be NULL here.
      
      xfrm_state4.c and state6.c are both part of ipv4/ipv6 (depends on
      CONFIG_XFRM, a boolean) but even if ipv6 is a module state6.c can't
      be removed (ipv6 lacks module_exit so it cannot be removed).
      
      The only callers for xfrm6_fini that leads to state backend unregister
      are error unwinding paths that can be called during ipv6 init function.
      
      So after ipv6 module is loaded successfully the state backend cannot go
      away anymore.
      
      The family value from policy lookup path is taken from dst_entry, so
      that should always be AF_INET(6).
      
      However, since this silences the warning and avoids readers of this
      code wondering about possible null deref it seems preferrable to
      be defensive and just add the old check back.
      
      Fixes: 711059b9 ("xfrm: add and use xfrm_state_afinfo_get_rcu")
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      3819a35f
  4. 10 Jan, 2017 5 commits
  5. 06 Jan, 2017 1 commit
    • Florian Westphal's avatar
      xfrm: state: do not acquire lock in get_mtu helpers · b3b73b8e
      Florian Westphal authored
      Once flow cache gets removed the mtu initialisation happens for every skb
      that gets an xfrm attached, so this lock starts to show up in perf.
      
      It is not obvious why this lock is required -- the caller holds
      reference on the state struct, type->destructor is only called from the
      state gc worker (all state structs on gc list must have refcount 0).
      
      xfrm_init_state already has been called (else private data accessed
      by type->get_mtu() would not be set up).
      
      So just remove the lock -- the race on the state (DEAD?) doesn't
      matter (could change right after dropping the lock too).
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      b3b73b8e
  6. 04 Jan, 2017 1 commit
  7. 02 Jan, 2017 25 commits