1. 13 Jul, 2012 1 commit
  2. 12 Jul, 2012 2 commits
  3. 11 Jul, 2012 20 commits
  4. 09 Jul, 2012 11 commits
    • Julia Lawall's avatar
      net/rxrpc/ar-peer.c: remove invalid reference to list iterator variable · cae296c4
      Julia Lawall authored
      If list_for_each_entry, etc complete a traversal of the list, the iterator
      variable ends up pointing to an address at an offset from the list head,
      and not a meaningful structure.  Thus this value should not be used after
      the end of the iterator.  This seems to be a copy-paste bug from a previous
      debugging message, and so the meaningless value is just deleted.
      
      This problem was found using Coccinelle (http://coccinelle.lip6.fr/
      
      ).
      Signed-off-by: default avatarJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cae296c4
    • Eric Dumazet's avatar
      net: cgroup: fix out of bounds accesses · 91c68ce2
      Eric Dumazet authored
      
      
      dev->priomap is allocated by extend_netdev_table() called from
      update_netdev_tables().
      And this is only called if write_priomap() is called.
      
      But if write_priomap() is not called, it seems we can have out of bounds
      accesses in cgrp_destroy(), read_priomap() & skb_update_prio()
      
      With help from Gao Feng
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: Gao feng <gaofeng@cn.fujitsu.com>
      Acked-by: default avatarGao feng <gaofeng@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      91c68ce2
    • Eliad Peller's avatar
      mac80211: destroy assoc_data correctly if assoc fails · 10a9109f
      Eliad Peller authored
      
      
      If association failed due to internal error (e.g. no
      supported rates IE), we call ieee80211_destroy_assoc_data()
      with assoc=true, while we actually reject the association.
      
      This results in the BSSID not being zeroed out.
      
      After passing assoc=false, we no longer have to call
      sta_info_destroy_addr() explicitly. While on it, move
      the "associated" message after the assoc_success check.
      
      Cc: stable@vger.kernel.org [3.4+]
      Signed-off-by: default avatarEliad Peller <eliad@wizery.com>
      Reviewed-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      10a9109f
    • Sasha Levin's avatar
      NFC: Prevent NULL deref when getting socket name · 147f20e3
      Sasha Levin authored
      
      
      llcp_sock_getname can be called without a device attached to the nfc_llcp_sock.
      
      This would lead to the following BUG:
      
      [  362.341807] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [  362.341815] IP: [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0
      [  362.341818] PGD 31b35067 PUD 30631067 PMD 0
      [  362.341821] Oops: 0000 [#627] PREEMPT SMP DEBUG_PAGEALLOC
      [  362.341826] CPU 3
      [  362.341827] Pid: 7816, comm: trinity-child55 Tainted: G      D W    3.5.0-rc4-next-20120628-sasha-00005-g9f23eb7 #479
      [  362.341831] RIP: 0010:[<ffffffff836258e5>]  [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0
      [  362.341832] RSP: 0018:ffff8800304fde88  EFLAGS: 00010286
      [  362.341834] RAX: 0000000000000000 RBX: ffff880033cb8000 RCX: 0000000000000001
      [  362.341835] RDX: ffff8800304fdec4 RSI: ffff8800304fdec8 RDI: ffff8800304fdeda
      [  362.341836] RBP: ffff8800304fdea8 R08: 7ebcebcb772b7ffb R09: 5fbfcb9c35bdfd53
      [  362.341838] R10: 4220020c54326244 R11: 0000000000000246 R12: ffff8800304fdec8
      [  362.341839] R13: ffff8800304fdec4 R14: ffff8800304fdec8 R15: 0000000000000044
      [  362.341841] FS:  00007effa376e700(0000) GS:ffff880035a00000(0000) knlGS:0000000000000000
      [  362.341843] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  362.341844] CR2: 0000000000000000 CR3: 0000000030438000 CR4: 00000000000406e0
      [  362.341851] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  362.341856] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  362.341858] Process trinity-child55 (pid: 7816, threadinfo ffff8800304fc000, task ffff880031270000)
      [  362.341858] Stack:
      [  362.341862]  ffff8800304fdea8 ffff880035156780 0000000000000000 0000000000001000
      [  362.341865]  ffff8800304fdf78 ffffffff83183b40 00000000304fdec8 0000006000000000
      [  362.341868]  ffff8800304f0027 ffffffff83729649 ffff8800304fdee8 ffff8800304fdf48
      [  362.341869] Call Trace:
      [  362.341874]  [<ffffffff83183b40>] sys_getpeername+0xa0/0x110
      [  362.341877]  [<ffffffff83729649>] ? _raw_spin_unlock_irq+0x59/0x80
      [  362.341882]  [<ffffffff810f342b>] ? do_setitimer+0x23b/0x290
      [  362.341886]  [<ffffffff81985ede>] ? trace_hardirqs_on_thunk+0x3a/0x3f
      [  362.341889]  [<ffffffff8372a539>] system_call_fastpath+0x16/0x1b
      [  362.341921] Code: 84 00 00 00 00 00 b8 b3 ff ff ff 48 85 db 74 54 66 41 c7 04 24 27 00 49 8d 7c 24 12 41 c7 45 00 60 00 00 00 48 8b 83 28 05 00 00 <8b> 00 41 89 44 24 04 0f b6 83 41 05 00 00 41 88 44 24 10 0f b6
      [  362.341924] RIP  [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0
      [  362.341925]  RSP <ffff8800304fde88>
      [  362.341926] CR2: 0000000000000000
      [  362.341928] ---[ end trace 6d450e935ee18bf3 ]---
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      147f20e3
    • Thomas Huehn's avatar
      mac80211: correct size the argument to kzalloc in minstrel_ht · 472dd35c
      Thomas Huehn authored
      
      
      msp has type struct minstrel_ht_sta_priv not struct minstrel_ht_sta.
      
      (This incorporates the fixup originally posted as "mac80211: fix kzalloc
      memory corruption introduced in minstrel_ht". -- JWL)
      Reported-by: default avatarFengguang Wu <wfg@linux.intel.com>
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarThomas Huehn <thomas@net.t-labs.tu-berlin.de>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      472dd35c
    • Jozsef Kadlecsik's avatar
      netfilter: ipset: timeout fixing bug broke SET target special timeout value · a73f89a6
      Jozsef Kadlecsik authored
      The patch "127f5591
      
       netfilter: ipset: fix timeout value overflow bug"
      broke the SET target when no timeout was specified.
      Reported-by: default avatarJean-Philippe Menil <jean-philippe.menil@univ-nantes.fr>
      Signed-off-by: default avatarJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      a73f89a6
    • Gao feng's avatar
      cgroup: fix panic in netprio_cgroup · b761c9b1
      Gao feng authored
      
      
      we set max_prioidx to the first zero bit index of prioidx_map in
      function get_prioidx.
      
      So when we delete the low index netprio cgroup and adding a new
      netprio cgroup again,the max_prioidx will be set to the low index.
      
      when we set the high index cgroup's net_prio.ifpriomap,the function
      write_priomap will call update_netdev_tables to alloc memory which
      size is sizeof(struct netprio_map) + sizeof(u32) * (max_prioidx + 1),
      so the size of array that map->priomap point to is max_prioidx +1,
      which is low than what we actually need.
      
      fix this by adding check in get_prioidx,only set max_prioidx when
      max_prioidx low than the new prioidx.
      Signed-off-by: default avatarGao feng <gaofeng@cn.fujitsu.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b761c9b1
    • Dan Carpenter's avatar
      small cleanup in ax25_addr_parse() · 5c9df5fe
      Dan Carpenter authored
      
      
      The comments were wrong here because "AX25_MAX_DIGIS" is 8 but the
      comments say 6.  Also I've changed the "7" to "AX25_ADDR_LEN".
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5c9df5fe
    • Eric Dumazet's avatar
      netem: add limitation to reordered packets · 960fb66e
      Eric Dumazet authored
      
      
      Fix two netem bugs :
      
      1) When a frame was dropped by tfifo_enqueue(), drop counter
         was incremented twice.
      
      2) When reordering is triggered, we enqueue a packet without
         checking queue limit. This can OOM pretty fast when this
         is repeated enough, since skbs are orphaned, no socket limit
         can help in this situation.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Mark Gordon <msg@google.com>
      Cc: Andreas Terzis <aterzis@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Hagen Paul Pfeifer <hagen@jauu.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      960fb66e
    • Neil Horman's avatar
      sctp: refactor sctp_packet_append_chunk and clenup some memory leaks · ed106277
      Neil Horman authored
      
      
      While doing some recent work on sctp sack bundling I noted that
      sctp_packet_append_chunk was pretty inefficient.  Specifially, it was called
      recursively while trying to bundle auth and sack chunks.  Because of that we
      call sctp_packet_bundle_sack and sctp_packet_bundle_auth a total of 4 times for
      every call to sctp_packet_append_chunk, knowing that at least 3 of those calls
      will do nothing.
      
      So lets refactor sctp_packet_bundle_auth to have an outer part that does the
      attempted bundling, and an inner part that just does the chunk appends.  This
      saves us several calls per iteration that we just don't need.
      
      Also, noticed that the auth and sack bundling fail to free the chunks they
      allocate if the append fails, so make sure we add that in
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      CC: Vlad Yasevich <vyasevich@gmail.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: linux-sctp@vger.kernel.org
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ed106277
    • Sasha Levin's avatar
      ieee802154: verify packet size before trying to allocate it · 3da947b2
      Sasha Levin authored
      
      
      Currently when sending data over datagram, the send function will attempt to
      allocate any size passed on from the userspace.
      
      We should make sure that this size is checked and limited. We'll limit it
      to the MTU of the device, which is checked later anyway.
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3da947b2
  5. 06 Jul, 2012 3 commits
  6. 05 Jul, 2012 3 commits