1. 09 2月, 2010 4 次提交
  2. 30 1月, 2010 3 次提交
  3. 27 1月, 2010 2 次提交
    • Z
      mac80211: fix NULL pointer dereference when ftrace is enabled · 3092ad05
      Zhu Yi 提交于
      I got below kernel oops when I try to bring down the network interface if
      ftrace is enabled. The root cause is drv_ampdu_action() is passed with a
      NULL ssn pointer in the BA session tear down case. We need to check and
      avoid dereferencing it in trace entry assignment.
      
      BUG: unable to handle kernel NULL pointer dereference
      Modules linked in: at (null)
      IP: [<f98fe02a>] ftrace_raw_event_drv_ampdu_action+0x10a/0x160 [mac80211]
      *pde = 00000000
      Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      [...]
      Call Trace:
       [<f98fdf20>] ? ftrace_raw_event_drv_ampdu_action+0x0/0x160 [mac80211]
       [<f98dac4c>] ? __ieee80211_stop_rx_ba_session+0xfc/0x220 [mac80211]
       [<f98d97fb>] ? ieee80211_sta_tear_down_BA_sessions+0x3b/0x50 [mac80211]
       [<f98dc6f6>] ? ieee80211_set_disassoc+0xe6/0x230 [mac80211]
       [<f98dc6ac>] ? ieee80211_set_disassoc+0x9c/0x230 [mac80211]
       [<f98dcbb8>] ? ieee80211_mgd_deauth+0x158/0x170 [mac80211]
       [<f98e4bdb>] ? ieee80211_deauth+0x1b/0x20 [mac80211]
       [<f8987f49>] ? __cfg80211_mlme_deauth+0xe9/0x120 [cfg80211]
       [<f898b870>] ? __cfg80211_disconnect+0x170/0x1d0 [cfg80211]
      
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: stable@kernel.org
      Signed-off-by: NZhu Yi <yi.zhu@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3092ad05
    • P
      netfilter: ctnetlink: fix expectation mask dump · e578756c
      Patrick McHardy 提交于
      The protocol number is not initialized, so userspace can't interpret
      the layer 4 data properly.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      e578756c
  4. 26 1月, 2010 2 次提交
  5. 25 1月, 2010 2 次提交
  6. 24 1月, 2010 1 次提交
  7. 20 1月, 2010 2 次提交
  8. 19 1月, 2010 2 次提交
    • N
      dccp: fix dccp rmmod when kernel configured to use slub · de4ef86c
      Neil Horman 提交于
      Hey all-
      	I was tinkering with dccp recently and noticed that I BUG halted the
      kernel when I rmmod-ed the dccp module.  The bug halt occured because the page
      that I passed to kfree failed the PageCompound and PageSlab test in the slub
      implementation of kfree.  I tracked the problem down to the following set of
      events:
      
      1) dccp, unlike all other uses of kmem_cache_create, allocates a string
      dynamically when registering a slab cache.  This allocated string is freed when
      the cache is destroyed.
      
      2) Normally, (1) is not an issue, but when Slub is in use, it is possible that
      caches are 'merged'.  This process causes multiple caches of simmilar
      configuration to use the same cache data structure.  When this happens, the new
      name of the cache is effectively dropped.
      
      3) (2) results in kmem_cache_name returning an ambigous value (i.e.
      ccid_kmem_cache_destroy, which uses this fuction to retrieve the name pointer
      for freeing), is no longer guaranteed that the string it assigned is what is
      returned.
      
      4) If such merge event occurs, ccid_kmem_cache_destroy frees the wrong pointer,
      which trips over the BUG in the slub implementation of kfree (since its likely
      not a slab allocation, but rather a pointer into the static string table
      section.
      
      So, what to do about this.  At first blush this is pretty clearly a leak in the
      information that slub owns, and as such a slub bug.  Unfortunately, theres no
      really good way to fix it, without exposing slub specific implementation details
      to the generic slab interface.  Also, even if we could fix this in slub cleanly,
      I think the RCU free option would force us to do lots of string duplication, not
      only in slub, but in every slab allocator.  As such, I'd like to propose this
      solution.  Basically, I just move the storage for the kmem cache name to the
      ccid_operations structure.  In so doing, we don't have to do the kstrdup or
      kfree when we allocate/free the various caches for dccp, and so we avoid the
      problem, by storing names with static memory, rather than heap, the way all
      other calls to kmem_cache_create do.
      
      I've tested this out myself here, and it solves the problem quite well.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      de4ef86c
    • B
      mac80211: fix sign error in pid controller · e850f68b
      Bob Copeland 提交于
      While testing the pid rate controller in mac80211_hwsim, I noticed
      that once the controller reached 54 Mbit rates, it would fail to
      lower the rate when necessary.  The debug log shows:
      
      1945 186786 pf_sample 50 3534 3577 50
      
      My interpretation is that the fixed point scaling of the target
      error value (pf) is incorrect: the error value of 50 compared to
      a target of 14 case should result in a scaling value of
      (14-50) = -36 * 256 or -9216, but instead it is (14 * 256)-50, or
      3534.
      
      Correct this by doing fixed point scaling after subtraction.
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Acked-by: NStefano Brivio <stefano.brivio@polimi.it>
      Acked-by: NMattias Nissler <mattias.nissler@gmx.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e850f68b
  9. 18 1月, 2010 1 次提交
  10. 16 1月, 2010 2 次提交
  11. 15 1月, 2010 3 次提交
  12. 14 1月, 2010 1 次提交
    • D
      ipv6: skb_dst() can be NULL in ipv6_hop_jumbo(). · 2570a4f5
      David S. Miller 提交于
      This fixes CERT-FI FICORA #341748
      
      Discovered by Olli Jarva and Tuomo Untinen from the CROSS
      project at Codenomicon Ltd.
      
      Just like in CVE-2007-4567, we can't rely upon skb_dst() being
      non-NULL at this point.  We fixed that in commit
      e76b2b25 ("[IPV6]: Do no rely on
      skb->dst before it is assigned.")
      
      However commit 483a47d2 ("ipv6: added
      net argument to IP6_INC_STATS_BH") put a new version of the same bug
      into this function.
      
      Complicating analysis further, this bug can only trigger when network
      namespaces are enabled in the build.  When namespaces are turned off,
      the dev_net() does not evaluate it's argument, so the dereference
      would not occur.
      
      So, for a long time, namespaces couldn't be turned on unless SYSFS was
      disabled.  Therefore, this code has largely been disabled except by
      people turning it on explicitly for namespace development.
      
      With help from Eugene Teo <eugene@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2570a4f5
  13. 12 1月, 2010 3 次提交
  14. 09 1月, 2010 4 次提交
  15. 08 1月, 2010 2 次提交
  16. 07 1月, 2010 5 次提交
  17. 06 1月, 2010 1 次提交
    • J
      mac80211: fix skb buffering issue · cf0277e7
      Johannes Berg 提交于
      Since I removed the master netdev, we've been
      keeping internal queues only, and even before
      that we never told the networking stack above
      the virtual interfaces about congestion. This
      means that packets are queued in mac80211 and
      the upper layers never know, possibly leading
      to memory exhaustion and other problems.
      
      This patch makes all interfaces multiqueue and
      uses ndo_select_queue to put the packets into
      queues per AC. Additionally, when the driver
      stops a queue, we now stop all corresponding
      queues for the virtual interfaces as well.
      
      The injection case will use VO by default for
      non-data frames, and BE for data frames, but
      downgrade any data frames according to ACM. It
      needs to be fleshed out in the future to allow
      chosing the queue/AC in radiotap.
      Reported-by: NLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Cc: stable@kernel.org [2.6.32]
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cf0277e7