1. 07 4月, 2015 1 次提交
    • A
      xfrm: fix xfrm_input/xfrm_tunnel_check oops · 68c11e98
      Alexey Dobriyan 提交于
      https://bugzilla.kernel.org/show_bug.cgi?id=95211
      
      Commit 70be6c91
      ("xfrm: Add xfrm_tunnel_skb_cb to the skb common buffer") added check
      which dereferences ->outer_mode too early but larval SAs don't have
      this pointer set (yet). So check for tunnel stuff later.
      
      Mike Noordermeer reported this bug and patiently applied all the debugging.
      
      Technically this is remote-oops-in-interrupt-context type of thing.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000034
      IP: [<ffffffff8150dca2>] xfrm_input+0x3c2/0x5a0
      	...
      [<ffffffff81500fc6>] ? xfrm4_esp_rcv+0x36/0x70
      [<ffffffff814acc9a>] ? ip_local_deliver_finish+0x9a/0x200
      [<ffffffff81471b83>] ? __netif_receive_skb_core+0x6f3/0x8f0
      	...
      
      RIP  [<ffffffff8150dca2>] xfrm_input+0x3c2/0x5a0
      Kernel panic - not syncing: Fatal exception in interrupt
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      68c11e98
  2. 12 2月, 2015 1 次提交
  3. 18 1月, 2015 1 次提交
    • J
      netlink: make nlmsg_end() and genlmsg_end() void · 053c095a
      Johannes Berg 提交于
      Contrary to common expectations for an "int" return, these functions
      return only a positive value -- if used correctly they cannot even
      return 0 because the message header will necessarily be in the skb.
      
      This makes the very common pattern of
      
        if (genlmsg_end(...) < 0) { ... }
      
      be a whole bunch of dead code. Many places also simply do
      
        return nlmsg_end(...);
      
      and the caller is expected to deal with it.
      
      This also commonly (at least for me) causes errors, because it is very
      common to write
      
        if (my_function(...))
          /* error condition */
      
      and if my_function() does "return nlmsg_end()" this is of course wrong.
      
      Additionally, there's not a single place in the kernel that actually
      needs the message length returned, and if anyone needs it later then
      it'll be very easy to just use skb->len there.
      
      Remove this, and make the functions void. This removes a bunch of dead
      code as described above. The patch adds lines because I did
      
      -	return nlmsg_end(...);
      +	nlmsg_end(...);
      +	return 0;
      
      I could have preserved all the function's return values by returning
      skb->len, but instead I've audited all the places calling the affected
      functions and found that none cared. A few places actually compared
      the return value with <= 0 in dump functionality, but that could just
      be changed to < 0 with no change in behaviour, so I opted for the more
      efficient version.
      
      One instance of the error I've made numerous times now is also present
      in net/phonet/pn_netlink.c in the route_dumpit() function - it didn't
      check for <0 or <=0 and thus broke out of the loop every single time.
      I've preserved this since it will (I think) have caused the messages to
      userspace to be formatted differently with just a single message for
      every SKB returned to userspace. It's possible that this isn't needed
      for the tools that actually use this, but I don't even know what they
      are so couldn't test that changing this behaviour would be acceptable.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      053c095a
  4. 13 1月, 2015 1 次提交
  5. 13 11月, 2014 2 次提交
    • H
      xfrm: Use __xfrm_policy_link in xfrm_policy_insert · 12bfa8bd
      Herbert Xu 提交于
      For a long time we couldn't actually use __xfrm_policy_link in
      xfrm_policy_insert because the latter wanted to do hashing at
      a specific position.
      
      Now that __xfrm_policy_link no longer does hashing it can now
      be safely used in xfrm_policy_insert to kill some duplicate code,
      finally reuniting general policies with socket policies.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      12bfa8bd
    • H
      xfrm: Do not hash socket policies · 53c2e285
      Herbert Xu 提交于
      Back in 2003 when I added policy expiration, I half-heartedly
      did a clean-up and renamed xfrm_sk_policy_link/xfrm_sk_policy_unlink
      to __xfrm_policy_link/__xfrm_policy_unlink, because the latter
      could be reused for all policies.  I never actually got around
      to using __xfrm_policy_link for non-socket policies.
      
      Later on hashing was added to all xfrm policies, including socket
      policies.  In fact, we don't need hashing on socket policies at
      all since they're always looked up via a linked list.
      
      This patch restores xfrm_sk_policy_link/xfrm_sk_policy_unlink
      as wrappers around __xfrm_policy_link/__xfrm_policy_unlink so
      that it's obvious we're dealing with socket policies.
      
      This patch also removes hashing from __xfrm_policy_link as for
      now it's only used by socket policies which do not need to be
      hashed.  Ironically this will in fact allow us to use this helper
      for non-socket policies which I shall do later.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      53c2e285
  6. 03 11月, 2014 1 次提交
  7. 31 10月, 2014 1 次提交
  8. 27 10月, 2014 1 次提交
  9. 21 10月, 2014 1 次提交
    • F
      net: make skb_gso_segment error handling more robust · 330966e5
      Florian Westphal 提交于
      skb_gso_segment has three possible return values:
      1. a pointer to the first segmented skb
      2. an errno value (IS_ERR())
      3. NULL.  This can happen when GSO is used for header verification.
      
      However, several callers currently test IS_ERR instead of IS_ERR_OR_NULL
      and would oops when NULL is returned.
      
      Note that these call sites should never actually see such a NULL return
      value; all callers mask out the GSO bits in the feature argument.
      
      However, there have been issues with some protocol handlers erronously not
      respecting the specified feature mask in some cases.
      
      It is preferable to get 'have to turn off hw offloading, else slow' reports
      rather than 'kernel crashes'.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      330966e5
  10. 02 10月, 2014 1 次提交
  11. 18 9月, 2014 1 次提交
    • H
      ipsec: Remove obsolete MAX_AH_AUTH_LEN · 689f1c9d
      Herbert Xu 提交于
      While tracking down the MAX_AH_AUTH_LEN crash in an old kernel
      I thought that this limit was rather arbitrary and we should
      just get rid of it.
      
      In fact it seems that we've already done all the work needed
      to remove it apart from actually removing it.  This limit was
      there in order to limit stack usage.  Since we've already
      switched over to allocating scratch space using kmalloc, there
      is no longer any need to limit the authentication length.
      
      This patch kills all references to it, including the BUG_ONs
      that led me here.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      689f1c9d
  12. 16 9月, 2014 2 次提交
  13. 10 9月, 2014 1 次提交
  14. 02 9月, 2014 2 次提交
    • C
      xfrm: configure policy hash table thresholds by netlink · 880a6fab
      Christophe Gouault 提交于
      Enable to specify local and remote prefix length thresholds for the
      policy hash table via a netlink XFRM_MSG_NEWSPDINFO message.
      
      prefix length thresholds are specified by XFRMA_SPD_IPV4_HTHRESH and
      XFRMA_SPD_IPV6_HTHRESH optional attributes (struct xfrmu_spdhthresh).
      
      example:
      
          struct xfrmu_spdhthresh thresh4 = {
              .lbits = 0;
              .rbits = 24;
          };
          struct xfrmu_spdhthresh thresh6 = {
              .lbits = 0;
              .rbits = 56;
          };
          struct nlmsghdr *hdr;
          struct nl_msg *msg;
      
          msg = nlmsg_alloc();
          hdr = nlmsg_put(msg, NL_AUTO_PORT, NL_AUTO_SEQ, XFRMA_SPD_IPV4_HTHRESH, sizeof(__u32), NLM_F_REQUEST);
          nla_put(msg, XFRMA_SPD_IPV4_HTHRESH, sizeof(thresh4), &thresh4);
          nla_put(msg, XFRMA_SPD_IPV6_HTHRESH, sizeof(thresh6), &thresh6);
          nla_send_auto(sk, msg);
      
      The numbers are the policy selector minimum prefix lengths to put a
      policy in the hash table.
      
      - lbits is the local threshold (source address for out policies,
        destination address for in and fwd policies).
      
      - rbits is the remote threshold (destination address for out
        policies, source address for in and fwd policies).
      
      The default values are:
      
      XFRMA_SPD_IPV4_HTHRESH: 32 32
      XFRMA_SPD_IPV6_HTHRESH: 128 128
      
      Dynamic re-building of the SPD is performed when the thresholds values
      are changed.
      
      The current thresholds can be read via a XFRM_MSG_GETSPDINFO request:
      the kernel replies to XFRM_MSG_GETSPDINFO requests by an
      XFRM_MSG_NEWSPDINFO message, with both attributes
      XFRMA_SPD_IPV4_HTHRESH and XFRMA_SPD_IPV6_HTHRESH.
      Signed-off-by: NChristophe Gouault <christophe.gouault@6wind.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      880a6fab
    • C
      xfrm: hash prefixed policies based on preflen thresholds · b58555f1
      Christophe Gouault 提交于
      The idea is an extension of the current policy hashing.
      
      Today only non-prefixed policies are stored in a hash table. This
      patch relaxes the constraints, and hashes policies whose prefix
      lengths are greater or equal to a configurable threshold.
      
      Each hash table (one per direction) maintains its own set of IPv4 and
      IPv6 thresholds (dbits4, sbits4, dbits6, sbits6), by default (32, 32,
      128, 128).
      
      Example, if the output hash table is configured with values (16, 24,
      56, 64):
      
      ip xfrm policy add dir out src 10.22.0.0/20 dst 10.24.1.0/24 ... => hashed
      ip xfrm policy add dir out src 10.22.0.0/16 dst 10.24.1.1/32 ... => hashed
      ip xfrm policy add dir out src 10.22.0.0/16 dst 10.24.0.0/16 ... => unhashed
      
      ip xfrm policy add dir out \
          src 3ffe:304:124:2200::/60 dst 3ffe:304:124:2401::/64 ...    => hashed
      ip xfrm policy add dir out \
          src 3ffe:304:124:2200::/56 dst 3ffe:304:124:2401::2/128 ...  => hashed
      ip xfrm policy add dir out \
          src 3ffe:304:124:2200::/56 dst 3ffe:304:124:2400::/56 ...    => unhashed
      
      The high order bits of the addresses (up to the threshold) are used to
      compute the hash key.
      Signed-off-by: NChristophe Gouault <christophe.gouault@6wind.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      b58555f1
  15. 29 8月, 2014 1 次提交
    • Y
      xfrm: remove useless hash_resize_mutex locks · 0244790c
      Ying Xue 提交于
      In xfrm_state.c, hash_resize_mutex is defined as a local variable
      and only used in xfrm_hash_resize() which is declared as a work
      handler of xfrm.state_hash_work. But when the xfrm.state_hash_work
      work is put in the global workqueue(system_wq) with schedule_work(),
      the work will be really inserted in the global workqueue if it was
      not already queued, otherwise, it is still left in the same position
      on the the global workqueue. This means the xfrm_hash_resize() work
      handler is only executed once at any time no matter how many times
      its work is scheduled, that is, xfrm_hash_resize() is not called
      concurrently at all, so hash_resize_mutex is redundant for us.
      
      Cc: Christophe Gouault <christophe.gouault@6wind.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      0244790c
  16. 07 8月, 2014 1 次提交
    • K
      list: fix order of arguments for hlist_add_after(_rcu) · 1d023284
      Ken Helias 提交于
      All other add functions for lists have the new item as first argument
      and the position where it is added as second argument.  This was changed
      for no good reason in this function and makes using it unnecessary
      confusing.
      
      The name was changed to hlist_add_behind() to cause unconverted code to
      generate a compile error instead of using the wrong parameter order.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NKen Helias <kenhelias@firemail.de>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>	[intel driver bits]
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1d023284
  17. 30 6月, 2014 1 次提交
  18. 26 6月, 2014 1 次提交
  19. 04 6月, 2014 1 次提交
    • M
      xfrm: fix race between netns cleanup and state expire notification · 21ee543e
      Michal Kubecek 提交于
      The xfrm_user module registers its pernet init/exit after xfrm
      itself so that its net exit function xfrm_user_net_exit() is
      executed before xfrm_net_exit() which calls xfrm_state_fini() to
      cleanup the SA's (xfrm states). This opens a window between
      zeroing net->xfrm.nlsk pointer and deleting all xfrm_state
      instances which may access it (via the timer). If an xfrm state
      expires in this window, xfrm_exp_state_notify() will pass null
      pointer as socket to nlmsg_multicast().
      
      As the notifications are called inside rcu_read_lock() block, it
      is sufficient to retrieve the nlsk socket with rcu_dereference()
      and check the it for null.
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      21ee543e
  20. 13 5月, 2014 1 次提交
  21. 08 5月, 2014 1 次提交
    • W
      net: clean up snmp stats code · 698365fa
      WANG Cong 提交于
      commit 8f0ea0fe (snmp: reduce percpu needs by 50%)
      reduced snmp array size to 1, so technically it doesn't have to be
      an array any more. What's more, after the following commit:
      
      	commit 933393f5
      	Date:   Thu Dec 22 11:58:51 2011 -0600
      
      	    percpu: Remove irqsafe_cpu_xxx variants
      
      	    We simply say that regular this_cpu use must be safe regardless of
      	    preemption and interrupt state.  That has no material change for x86
      	    and s390 implementations of this_cpu operations.  However, arches that
      	    do not provide their own implementation for this_cpu operations will
      	    now get code generated that disables interrupts instead of preemption.
      
      probably no arch wants to have SNMP_ARRAY_SZ == 2. At least after
      almost 3 years, no one complains.
      
      So, just convert the array to a single pointer and remove snmp_mib_init()
      and snmp_mib_free() as well.
      
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      698365fa
  22. 25 4月, 2014 1 次提交
  23. 23 4月, 2014 1 次提交
  24. 22 4月, 2014 1 次提交
    • T
      xfrm: Remove useless secid field from xfrm_audit. · f1370cc4
      Tetsuo Handa 提交于
      It seems to me that commit ab5f5e8b "[XFRM]: xfrm audit calls" is doing
      something strange at xfrm_audit_helper_usrinfo().
      If secid != 0 && security_secid_to_secctx(secid) != 0, the caller calls
      audit_log_task_context() which basically does
      secid != 0 && security_secid_to_secctx(secid) == 0 case
      except that secid is obtained from current thread's context.
      
      Oh, what happens if secid passed to xfrm_audit_helper_usrinfo() was
      obtained from other thread's context? It might audit current thread's
      context rather than other thread's context if security_secid_to_secctx()
      in xfrm_audit_helper_usrinfo() failed for some reason.
      
      Then, are all the caller of xfrm_audit_helper_usrinfo() passing either
      secid obtained from current thread's context or secid == 0?
      It seems to me that they are.
      
      If I didn't miss something, we don't need to pass secid to
      xfrm_audit_helper_usrinfo() because audit_log_task_context() will
      obtain secid from current thread's context.
      Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      f1370cc4
  25. 16 4月, 2014 1 次提交
  26. 14 3月, 2014 1 次提交
  27. 13 3月, 2014 1 次提交
  28. 10 3月, 2014 1 次提交
    • N
      selinux: add gfp argument to security_xfrm_policy_alloc and fix callers · 52a4c640
      Nikolay Aleksandrov 提交于
      security_xfrm_policy_alloc can be called in atomic context so the
      allocation should be done with GFP_ATOMIC. Add an argument to let the
      callers choose the appropriate way. In order to do so a gfp argument
      needs to be added to the method xfrm_policy_alloc_security in struct
      security_operations and to the internal function
      selinux_xfrm_alloc_user. After that switch to GFP_ATOMIC in the atomic
      callers and leave GFP_KERNEL as before for the rest.
      The path that needed the gfp argument addition is:
      security_xfrm_policy_alloc -> security_ops.xfrm_policy_alloc_security ->
      all users of xfrm_policy_alloc_security (e.g. selinux_xfrm_policy_alloc) ->
      selinux_xfrm_alloc_user (here the allocation used to be GFP_KERNEL only)
      
      Now adding a gfp argument to selinux_xfrm_alloc_user requires us to also
      add it to security_context_to_sid which is used inside and prior to this
      patch did only GFP_KERNEL allocation. So add gfp argument to
      security_context_to_sid and adjust all of its callers as well.
      
      CC: Paul Moore <paul@paul-moore.com>
      CC: Dave Jones <davej@redhat.com>
      CC: Steffen Klassert <steffen.klassert@secunet.com>
      CC: Fan Du <fan.du@windriver.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: LSM list <linux-security-module@vger.kernel.org>
      CC: SELinux list <selinux@tycho.nsa.gov>
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Acked-by: NPaul Moore <paul@paul-moore.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      52a4c640
  29. 07 3月, 2014 1 次提交
  30. 26 2月, 2014 1 次提交
  31. 25 2月, 2014 2 次提交
  32. 21 2月, 2014 1 次提交
  33. 20 2月, 2014 3 次提交
  34. 19 2月, 2014 1 次提交