1. 25 4月, 2014 2 次提交
  2. 12 4月, 2014 1 次提交
    • D
      net: Fix use after free by removing length arg from sk_data_ready callbacks. · 676d2369
      David S. Miller 提交于
      Several spots in the kernel perform a sequence like:
      
      	skb_queue_tail(&sk->s_receive_queue, skb);
      	sk->sk_data_ready(sk, skb->len);
      
      But at the moment we place the SKB onto the socket receive queue it
      can be consumed and freed up.  So this skb->len access is potentially
      to freed up memory.
      
      Furthermore, the skb->len can be modified by the consumer so it is
      possible that the value isn't accurate.
      
      And finally, no actual implementation of this callback actually uses
      the length argument.  And since nobody actually cared about it's
      value, lots of call sites pass arbitrary values in such as '0' and
      even '1'.
      
      So just remove the length argument from the callback, that way there
      is no confusion whatsoever and all of these use-after-free cases get
      fixed as a side effect.
      
      Based upon a patch by Eric Dumazet and his suggestion to audit this
      issue tree-wide.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      676d2369
  3. 11 3月, 2014 1 次提交
    • E
      netlink: autosize skb lengthes · 9063e21f
      Eric Dumazet 提交于
      One known problem with netlink is the fact that NLMSG_GOODSIZE is
      really small on PAGE_SIZE==4096 architectures, and it is difficult
      to know in advance what buffer size is used by the application.
      
      This patch adds an automatic learning of the size.
      
      First netlink message will still be limited to ~4K, but if user used
      bigger buffers, then following messages will be able to use up to 16KB.
      
      This speedups dump() operations by a large factor and should be safe
      for legacy applications.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Thomas Graf <tgraf@suug.ch>
      Acked-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9063e21f
  4. 26 2月, 2014 1 次提交
  5. 18 2月, 2014 1 次提交
  6. 19 1月, 2014 1 次提交
  7. 07 1月, 2014 1 次提交
  8. 02 1月, 2014 1 次提交
  9. 01 1月, 2014 2 次提交
    • D
      netlink: specify netlink packet direction for nlmon · 604d13c9
      Daniel Borkmann 提交于
      In order to facilitate development for netlink protocol dissector,
      fill the unused field skb->pkt_type of the cloned skb with a hint
      of the address space of the new owner (receiver) socket in the
      notion of "to kernel" resp. "to user".
      
      At the time we invoke __netlink_deliver_tap_skb(), we already have
      set the new skb owner via netlink_skb_set_owner_r(), so we can use
      that for netlink_is_kernel() probing.
      
      In normal PF_PACKET network traffic, this field denotes if the
      packet is destined for us (PACKET_HOST), if it's broadcast
      (PACKET_BROADCAST), etc.
      
      As we only have 3 bit reserved, we can use the value (= 6) of
      PACKET_FASTROUTE as it's _not used_ anywhere in the whole kernel
      and not supported anywhere, and packets of such type were never
      exposed to user space, so there are no overlapping users of such
      kind. Thus, as wished, that seems the only way to make both
      PACKET_* values non-overlapping and therefore device agnostic.
      
      By using those two flags for netlink skbs on nlmon devices, they
      can be made available and picked up via sll_pkttype (previously
      unused in netlink context) in struct sockaddr_ll. We now have
      these two directions:
      
       - PACKET_USER (= 6)    ->  to user space
       - PACKET_KERNEL (= 7)  ->  to kernel space
      
      Partial `ip a` example strace for sa_family=AF_NETLINK with
      detected nl msg direction:
      
      syscall:                     direction:
      sendto(3,  ...) = 40         /* to kernel */
      recvmsg(3, ...) = 3404       /* to user */
      recvmsg(3, ...) = 1120       /* to user */
      recvmsg(3, ...) = 20         /* to user */
      sendto(3,  ...) = 40         /* to kernel */
      recvmsg(3, ...) = 168        /* to user */
      recvmsg(3, ...) = 144        /* to user */
      recvmsg(3, ...) = 20         /* to user */
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NJakub Zawadzki <darkjames-ws@darkjames.pl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      604d13c9
    • D
      netlink: only do not deliver to tap when both sides are kernel sks · 73bfd370
      Daniel Borkmann 提交于
      We should also deliver packets to nlmon devices when we are in
      netlink_unicast_kernel(), and only one of the {src,dst} sockets
      is user sk and the other one kernel sk. That's e.g. the case in
      netlink diag, netlink route, etc. Still, forbid to deliver messages
      from kernel to kernel sks.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NJakub Zawadzki <darkjames-ws@darkjames.pl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73bfd370
  10. 21 11月, 2013 1 次提交
    • H
      net: rework recvmsg handler msg_name and msg_namelen logic · f3d33426
      Hannes Frederic Sowa 提交于
      This patch now always passes msg->msg_namelen as 0. recvmsg handlers must
      set msg_namelen to the proper size <= sizeof(struct sockaddr_storage)
      to return msg_name to the user.
      
      This prevents numerous uninitialized memory leaks we had in the
      recvmsg handlers and makes it harder for new code to accidentally leak
      uninitialized memory.
      
      Optimize for the case recvfrom is called with NULL as address. We don't
      need to copy the address at all, so set it to NULL before invoking the
      recvmsg handler. We can do so, because all the recvmsg handlers must
      cope with the case a plain read() is called on them. read() also sets
      msg_name to NULL.
      
      Also document these changes in include/linux/net.h as suggested by David
      Miller.
      
      Changes since RFC:
      
      Set msg->msg_name = NULL if user specified a NULL in msg_name but had a
      non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
      affect sendto as it would bail out earlier while trying to copy-in the
      address. It also more naturally reflects the logic by the callers of
      verify_iovec.
      
      With this change in place I could remove "
      if (!uaddr || msg_sys->msg_namelen == 0)
      	msg->msg_name = NULL
      ".
      
      This change does not alter the user visible error logic as we ignore
      msg_namelen as long as msg_name is NULL.
      
      Also remove two unnecessary curly brackets in ___sys_recvmsg and change
      comments to netdev style.
      
      Cc: David Miller <davem@davemloft.net>
      Suggested-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f3d33426
  11. 20 11月, 2013 1 次提交
  12. 07 9月, 2013 1 次提交
  13. 16 8月, 2013 1 次提交
  14. 03 8月, 2013 1 次提交
  15. 28 6月, 2013 1 次提交
    • P
      netlink: fix splat in skb_clone with large messages · 3a36515f
      Pablo Neira 提交于
      Since (c05cdb1b netlink: allow large data transfers from user-space),
      netlink splats if it invokes skb_clone on large netlink skbs since:
      
      * skb_shared_info was not correctly initialized.
      * skb->destructor is not set in the cloned skb.
      
      This was spotted by trinity:
      
      [  894.990671] BUG: unable to handle kernel paging request at ffffc9000047b001
      [  894.991034] IP: [<ffffffff81a212c4>] skb_clone+0x24/0xc0
      [...]
      [  894.991034] Call Trace:
      [  894.991034]  [<ffffffff81ad299a>] nl_fib_input+0x6a/0x240
      [  894.991034]  [<ffffffff81c3b7e6>] ? _raw_read_unlock+0x26/0x40
      [  894.991034]  [<ffffffff81a5f189>] netlink_unicast+0x169/0x1e0
      [  894.991034]  [<ffffffff81a601e1>] netlink_sendmsg+0x251/0x3d0
      
      Fix it by:
      
      1) introducing a new netlink_skb_clone function that is used in nl_fib_input,
         that sets our special skb->destructor in the cloned skb. Moreover, handle
         the release of the large cloned skb head area in the destructor path.
      
      2) not allowing large skbuffs in the netlink broadcast path. I cannot find
         any reasonable use of the large data transfer using netlink in that path,
         moreover this helps to skip extra skb_clone handling.
      
      I found two more netlink clients that are cloning the skbs, but they are
      not in the sendmsg path. Therefore, the sole client cloning that I found
      seems to be the fib frontend.
      
      Thanks to Eric Dumazet for helping to address this issue.
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3a36515f
  16. 25 6月, 2013 1 次提交
    • D
      net: netlink: virtual tap device management · bcbde0d4
      Daniel Borkmann 提交于
      Similarly to the networking receive path with ptype_all taps, we add
      the possibility to register netdevices that are for ARPHRD_NETLINK to
      the netlink subsystem, so that those can be used for netlink analyzers
      resp. debuggers. We do not offer a direct callback function as out-of-tree
      modules could do crap with it. Instead, a netdevice must be registered
      properly and only receives a clone, managed by the netlink layer. Symbols
      are exported as GPL-only.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bcbde0d4
  17. 13 6月, 2013 1 次提交
  18. 11 6月, 2013 2 次提交
  19. 08 6月, 2013 1 次提交
    • P
      netlink: allow large data transfers from user-space · c05cdb1b
      Pablo Neira Ayuso 提交于
      I can hit ENOBUFS in the sendmsg() path with a large batch that is
      composed of many netlink messages. Here that limit is 8 MBytes of
      skbuff data area as kmalloc does not manage to get more than that.
      
      While discussing atomic rule-set for nftables with Patrick McHardy,
      we decided to put all rule-set updates that need to be applied
      atomically in one single batch to simplify the existing approach.
      However, as explained above, the existing netlink code limits us
      to a maximum of ~20000 rules that fit in one single batch without
      hitting ENOBUFS. iptables does not have such limitation as it is
      using vmalloc.
      
      This patch adds netlink_alloc_large_skb() which is only used in
      the netlink_sendmsg() path. It uses alloc_skb if the memory
      requested is <= one memory page, that should be the common case
      for most subsystems, else vmalloc for higher memory allocations.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c05cdb1b
  20. 05 6月, 2013 1 次提交
  21. 02 5月, 2013 1 次提交
  22. 25 4月, 2013 1 次提交
    • N
      netlink: fix compilation after memory mapped patches · 1bf9310a
      Nicolas Dichtel 提交于
      Depending of the kernel configuration (CONFIG_UIDGID_STRICT_TYPE_CHECKS), we can
      get the following errors:
      
      net/netlink/af_netlink.c: In function ‘netlink_queue_mmaped_skb’:
      net/netlink/af_netlink.c:663:14: error: incompatible types when assigning to type ‘__u32’ from type ‘kuid_t’
      net/netlink/af_netlink.c:664:14: error: incompatible types when assigning to type ‘__u32’ from type ‘kgid_t’
      net/netlink/af_netlink.c: In function ‘netlink_ring_set_copied’:
      net/netlink/af_netlink.c:693:14: error: incompatible types when assigning to type ‘__u32’ from type ‘kuid_t’
      net/netlink/af_netlink.c:694:14: error: incompatible types when assigning to type ‘__u32’ from type ‘kgid_t’
      
      We must use the helpers to get the uid and gid, and also take care of user_ns.
      
      Fix suggested by Eric W. Biederman <ebiederm@xmission.com>.
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1bf9310a
  23. 24 4月, 2013 1 次提交
  24. 20 4月, 2013 9 次提交
  25. 29 3月, 2013 1 次提交
  26. 22 3月, 2013 1 次提交
  27. 28 2月, 2013 1 次提交
    • S
      hlist: drop the node parameter from iterators · b67bfe0d
      Sasha Levin 提交于
      I'm not sure why, but the hlist for each entry iterators were conceived
      
              list_for_each_entry(pos, head, member)
      
      The hlist ones were greedy and wanted an extra parameter:
      
              hlist_for_each_entry(tpos, pos, head, member)
      
      Why did they need an extra pos parameter? I'm not quite sure. Not only
      they don't really need it, it also prevents the iterator from looking
      exactly like the list iterator, which is unfortunate.
      
      Besides the semantic patch, there was some manual work required:
      
       - Fix up the actual hlist iterators in linux/list.h
       - Fix up the declaration of other iterators based on the hlist ones.
       - A very small amount of places were using the 'node' parameter, this
       was modified to use 'obj->member' instead.
       - Coccinelle didn't handle the hlist_for_each_entry_safe iterator
       properly, so those had to be fixed up manually.
      
      The semantic patch which is mostly the work of Peter Senna Tschudin is here:
      
      @@
      iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
      
      type T;
      expression a,c,d,e;
      identifier b;
      statement S;
      @@
      
      -T b;
          <+... when != b
      (
      hlist_for_each_entry(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_continue(a,
      - b,
      c) S
      |
      hlist_for_each_entry_from(a,
      - b,
      c) S
      |
      hlist_for_each_entry_rcu(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_rcu_bh(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_continue_rcu_bh(a,
      - b,
      c) S
      |
      for_each_busy_worker(a, c,
      - b,
      d) S
      |
      ax25_uid_for_each(a,
      - b,
      c) S
      |
      ax25_for_each(a,
      - b,
      c) S
      |
      inet_bind_bucket_for_each(a,
      - b,
      c) S
      |
      sctp_for_each_hentry(a,
      - b,
      c) S
      |
      sk_for_each(a,
      - b,
      c) S
      |
      sk_for_each_rcu(a,
      - b,
      c) S
      |
      sk_for_each_from
      -(a, b)
      +(a)
      S
      + sk_for_each_from(a) S
      |
      sk_for_each_safe(a,
      - b,
      c, d) S
      |
      sk_for_each_bound(a,
      - b,
      c) S
      |
      hlist_for_each_entry_safe(a,
      - b,
      c, d, e) S
      |
      hlist_for_each_entry_continue_rcu(a,
      - b,
      c) S
      |
      nr_neigh_for_each(a,
      - b,
      c) S
      |
      nr_neigh_for_each_safe(a,
      - b,
      c, d) S
      |
      nr_node_for_each(a,
      - b,
      c) S
      |
      nr_node_for_each_safe(a,
      - b,
      c, d) S
      |
      - for_each_gfn_sp(a, c, d, b) S
      + for_each_gfn_sp(a, c, d) S
      |
      - for_each_gfn_indirect_valid_sp(a, c, d, b) S
      + for_each_gfn_indirect_valid_sp(a, c, d) S
      |
      for_each_host(a,
      - b,
      c) S
      |
      for_each_host_safe(a,
      - b,
      c, d) S
      |
      for_each_mesh_entry(a,
      - b,
      c, d) S
      )
          ...+>
      
      [akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
      [akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
      [akpm@linux-foundation.org: checkpatch fixes]
      [akpm@linux-foundation.org: fix warnings]
      [akpm@linux-foudnation.org: redo intrusive kvm changes]
      Tested-by: NPeter Senna Tschudin <peter.senna@gmail.com>
      Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b67bfe0d
  28. 23 2月, 2013 1 次提交
  29. 19 2月, 2013 1 次提交