1. 10 2月, 2010 3 次提交
  2. 09 2月, 2010 6 次提交
  3. 30 1月, 2010 3 次提交
  4. 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
  5. 26 1月, 2010 2 次提交
  6. 25 1月, 2010 2 次提交
  7. 24 1月, 2010 1 次提交
  8. 20 1月, 2010 2 次提交
  9. 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
  10. 18 1月, 2010 1 次提交
  11. 16 1月, 2010 2 次提交
  12. 15 1月, 2010 3 次提交
  13. 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
  14. 12 1月, 2010 3 次提交
  15. 09 1月, 2010 4 次提交
  16. 08 1月, 2010 2 次提交
  17. 07 1月, 2010 1 次提交
    • O
      ip: fix mc_loop checks for tunnels with multicast outer addresses · 7ad6848c
      Octavian Purdila 提交于
      When we have L3 tunnels with different inner/outer families
      (i.e. IPV4/IPV6) which use a multicast address as the outer tunnel
      destination address, multicast packets will be loopbacked back to the
      sending socket even if IP*_MULTICAST_LOOP is set to disabled.
      
      The mc_loop flag is present in the family specific part of the socket
      (e.g. the IPv4 or IPv4 specific part).  setsockopt sets the inner
      family mc_loop flag. When the packet is pushed through the L3 tunnel
      it will eventually be processed by the outer family which if different
      will check the flag in a different part of the socket then it was set.
      Signed-off-by: NOctavian Purdila <opurdila@ixiacom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7ad6848c