1. 20 1月, 2010 1 次提交
  2. 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
  3. 18 1月, 2010 1 次提交
  4. 16 1月, 2010 2 次提交
  5. 15 1月, 2010 3 次提交
  6. 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
  7. 12 1月, 2010 3 次提交
  8. 09 1月, 2010 4 次提交
  9. 08 1月, 2010 2 次提交
  10. 07 1月, 2010 5 次提交
  11. 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
  12. 05 1月, 2010 1 次提交
  13. 04 1月, 2010 3 次提交
    • A
      ipvs: Add boundary check on ioctl arguments · 04bcef2a
      Arjan van de Ven 提交于
      The ipvs code has a nifty system for doing the size of ioctl command
      copies; it defines an array with values into which it indexes the cmd
      to find the right length.
      
      Unfortunately, the ipvs code forgot to check if the cmd was in the
      range that the array provides, allowing for an index outside of the
      array, which then gives a "garbage" result into the length, which
      then gets used for copying into a stack buffer.
      
      Fix this by adding sanity checks on these as well as the copy size.
      
      [ horms@verge.net.au: adjusted limit to IP_VS_SO_GET_MAX ]
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Acked-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      04bcef2a
    • A
      net/sctp/socket.c: squish warning · 8ffd3208
      Andrew Morton 提交于
      net/sctp/socket.c: In function 'sctp_setsockopt_autoclose':
      net/sctp/socket.c:2090: warning: comparison is always false due to limited range of data type
      
      Cc: Andrei Pelinescu-Onciul <andrei@iptel.org>
      Cc: Vlad Yasevich <vladislav.yasevich@hp.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8ffd3208
    • B
      rose_loopback_timer sets VC number <= ROSE_DEFAULT_MAXVC · 1f731b63
      Bernard Pidoux F6BVP 提交于
      cat /proc/net/rose displayed a rose sockets abnormal lci value, i.e.
      greater than maximum number of VCs per neighbour allowed.
      This number prevents further test of lci value during rose operations.
      
      Example (lines shortened) :
      [bernard]# cat /proc/net/rose
      dest_addr  dest_call src_addr   src_call  dev   lci neigh st vs vr va
      *          *         2080175520 F6BVP-1   rose0 000 00000  0  0  0  0
      2080175520 FPAD-0    2080175520 WP-0      rose0 FFE 00001  3  0  0  0
      
      Here are the default parameters :
      
      linux/include/net/rose.h:#define ROSE_DEFAULT_MAXVC 50 /* Maximum number of VCs per neighbour */
      linux/net/rose/af_rose.c:int sysctl_rose_maximum_vcs = ROSE_DEFAULT_MAXVC;
      
      With the following patch, rose_loopback_timer() attributes a VC number
      within limits.
      Signed-off-by: NBernard Pidoux <f6bvp@amsat.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1f731b63
  14. 29 12月, 2009 5 次提交
    • L
      mac80211: fix propagation of failed hardware reconfigurations · 24feda00
      Luis R. Rodriguez 提交于
      mac80211 does not propagate failed hardware reconfiguration
      requests. For suspend and resume this is important due to all
      the possible issues that can come out of the suspend <-> resume
      cycle. Not propagating the error means cfg80211 will assume
      the resume for the device went through fine and mac80211 will
      continue on trying to poke at the hardware, enable timers,
      queue work, and so on for a device which is completley
      unfunctional.
      
      The least we can do is to propagate device start issues and
      warn when this occurs upon resume. A side effect of this patch
      is we also now propagate the start errors upon harware
      reconfigurations (non-suspend), but this should also be desirable
      anyway, there is not point in continuing to reconfigure a
      device if mac80211 was unable to start the device.
      
      For further details refer to the thread:
      
      http://marc.info/?t=126151038700001&r=1&w=2
      
      Cc: stable@kernel.org
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      24feda00
    • L
      mac80211: fix race with suspend and dynamic_ps_disable_work · b98c06b6
      Luis R. Rodriguez 提交于
      When mac80211 suspends it calls a driver's suspend callback
      as a last step and after that the driver assumes no calls will
      be made to it until we resume and its start callback is kicked.
      If such calls are made, however, suspend can end up throwing
      hardware in an unexpected state and making the device unusable
      upon resume.
      
      Fix this by preventing mac80211 to schedule dynamic_ps_disable_work
      by checking for when mac80211 starts to suspend and starts
      quiescing. Frames should be allowed to go through though as
      that is part of the quiescing steps and we do not flush the
      mac80211 workqueue since it was already done towards the
      beginning of suspend cycle.
      
      The other mac80211 issue will be hanled in the next patch.
      
      For further details see refer to the thread:
      
      http://marc.info/?t=126144866100001&r=1&w=2
      
      Cc: stable@kernel.org
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b98c06b6
    • J
      cfg80211: fix error path in cfg80211_wext_siwscan · 65486c8b
      Johannes Berg 提交于
      If there's an invalid channel or SSID, the code leaks
      the scan request. Always free the scan request, unless
      it was successfully given to the driver.
      Reported-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Acked-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      65486c8b
    • J
      cfg80211: fix race between deauth and assoc response · 3bdb2d48
      Johannes Berg 提交于
      Joseph Nahmias reported, in http://bugs.debian.org/562016,
      that he was getting the following warning (with some log
      around the issue):
      
        ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1)
        ath0: direct probe responded
        ath0: authenticate with AP 00:11:95:77:e0:b0 (try 1)
        ath0: authenticated
        ath0: associate with AP 00:11:95:77:e0:b0 (try 1)
        ath0: deauthenticating from 00:11:95:77:e0:b0 by local choice (reason=3)
        ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1)
        ath0: RX AssocResp from 00:11:95:77:e0:b0 (capab=0x421 status=0 aid=2)
        ath0: associated
        ------------[ cut here ]------------
        WARNING: at net/wireless/mlme.c:97 cfg80211_send_rx_assoc+0x14d/0x152 [cfg80211]()
        Hardware name: 7658CTO
        ...
        Pid: 761, comm: phy0 Not tainted 2.6.32-trunk-686 #1
        Call Trace:
         [<c1030a5d>] ? warn_slowpath_common+0x5e/0x8a
         [<c1030a93>] ? warn_slowpath_null+0xa/0xc
         [<f86cafc7>] ? cfg80211_send_rx_assoc+0x14d/0x152
        ...
        ath0: link becomes ready
        ath0: deauthenticating from 00:11:95:77:e0:b0 by local choice (reason=3)
        ath0: no IPv6 routers present
        ath0: link is not ready
        ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1)
        ath0: direct probe responded
        ath0: authenticate with AP 00:11:95:77:e0:b0 (try 1)
        ath0: authenticated
        ath0: associate with AP 00:11:95:77:e0:b0 (try 1)
        ath0: RX ReassocResp from 00:11:95:77:e0:b0 (capab=0x421 status=0 aid=2)
        ath0: associated
      
      It is not clear to me how the first "direct probe" here
      happens, but this seems to be a race condition, if the
      user requests to deauth after requesting assoc, but before
      the assoc response is received. In that case, it may
      happen that mac80211 tries to report the assoc success to
      cfg80211, but gets blocked on the wdev lock that is held
      because the user is requesting the deauth.
      
      The result is that we run into a warning. This is mostly
      harmless, but maybe cause an unexpected event to be sent
      to userspace; we'd send an assoc success event although
      userspace was no longer expecting that.
      
      To fix this, remove the warning and check whether the
      race happened and in that case abort processing.
      Reported-by: NJoseph Nahmias <joe@nahmias.net>
      Cc: stable@kernel.org
      Cc: 562016-quiet@bugs.debian.org
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3bdb2d48
    • F
      mac80211: fix ibss join with fixed-bssid · 2e10d330
      Felix Fietkau 提交于
      When fixed bssid is requested when joining an ibss network, incoming
      beacons that match the configured bssid cause mac80211 to create new
      sta entries, even before the ibss interface is in joined state.
      When that happens, it fails to bring up the interface entirely, because
      it checks for existing sta entries before joining.
      This patch fixes this bug by refusing to create sta info entries before
      the interface is fully operational.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2e10d330
  15. 27 12月, 2009 1 次提交
  16. 26 12月, 2009 1 次提交
    • J
      net: restore ip source validation · 28f6aeea
      Jamal Hadi Salim 提交于
      when using policy routing and the skb mark:
      there are cases where a back path validation requires us
      to use a different routing table for src ip validation than
      the one used for mapping ingress dst ip.
      One such a case is transparent proxying where we pretend to be
      the destination system and therefore the local table
      is used for incoming packets but possibly a main table would
      be used on outbound.
      Make the default behavior to allow the above and if users
      need to turn on the symmetry via sysctl src_valid_mark
      Signed-off-by: NJamal Hadi Salim <hadi@cyberus.ca>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      28f6aeea
  17. 24 12月, 2009 1 次提交
  18. 23 12月, 2009 3 次提交