You need to sign in or sign up before continuing.
  1. 01 11月, 2011 1 次提交
  2. 25 11月, 2010 1 次提交
  3. 01 9月, 2010 1 次提交
  4. 31 8月, 2010 1 次提交
    • J
      wireless extensions: fix kernel heap content leak · 42da2f94
      Johannes Berg 提交于
      Wireless extensions have an unfortunate, undocumented
      requirement which requires drivers to always fill
      iwp->length when returning a successful status. When
      a driver doesn't do this, it leads to a kernel heap
      content leak when userspace offers a larger buffer
      than would have been necessary.
      
      Arguably, this is a driver bug, as it should, if it
      returns 0, fill iwp->length, even if it separately
      indicated that the buffer contents was not valid.
      
      However, we can also at least avoid the memory content
      leak if the driver doesn't do this by setting the iwp
      length to max_tokens, which then reflects how big the
      buffer is that the driver may fill, regardless of how
      big the userspace buffer is.
      
      To illustrate the point, this patch also fixes a
      corresponding cfg80211 bug (since this requirement
      isn't documented nor was ever pointed out by anyone
      during code review, I don't trust all drivers nor
      all cfg80211 handlers to implement it correctly).
      
      Cc: stable@kernel.org [all the way back]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      42da2f94
  5. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  6. 24 3月, 2010 2 次提交
  7. 05 12月, 2009 1 次提交
    • J
      WE: Fix set events not propagated · 1014eb6e
      Jean Tourrilhes 提交于
      I've just noticed that some events are no longer propagated
      for some wireless drivers. Basically, SET request with a extra payload
      for driver without commit handler. The fix is pretty simple, see
      attached.
      	Actually, a few lines below this line, you will see that the
      event generation for simple SET (iwpoint-less ?) is done properly,
      and this other event generation does not need fixing.
      Signed-off-by: NJean Tourrilhes <jt@hpl.hp.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1014eb6e
  8. 30 11月, 2009 1 次提交
  9. 08 10月, 2009 1 次提交
    • J
      wext: refactor · 3d23e349
      Johannes Berg 提交于
      Refactor wext to
       * split out iwpriv handling
       * split out iwspy handling
       * split out procfs support
       * allow cfg80211 to have wireless extensions compat code
         w/o CONFIG_WIRELESS_EXT
      
      After this, drivers need to
       - select WIRELESS_EXT	- for wext support
       - select WEXT_PRIV	- for iwpriv support
       - select WEXT_SPY	- for iwspy support
      
      except cfg80211 -- which gets new hooks in wext-core.c
      and can then get wext handlers without CONFIG_WIRELESS_EXT.
      
      Wireless extensions procfs support is auto-selected
      based on PROC_FS and anything that requires the wext core
      (i.e. WIRELESS_EXT or CFG80211_WEXT).
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3d23e349
  10. 29 9月, 2009 2 次提交
  11. 05 8月, 2009 1 次提交
  12. 15 7月, 2009 3 次提交
    • J
      net/compat/wext: send different messages to compat tasks · 1dacc76d
      Johannes Berg 提交于
      Wireless extensions have the unfortunate problem that events
      are multicast netlink messages, and are not independent of
      pointer size. Thus, currently 32-bit tasks on 64-bit platforms
      cannot properly receive events and fail with all kinds of
      strange problems, for instance wpa_supplicant never notices
      disassociations, due to the way the 64-bit event looks (to a
      32-bit process), the fact that the address is all zeroes is
      lost, it thinks instead it is 00:00:00:00:01:00.
      
      The same problem existed with the ioctls, until David Miller
      fixed those some time ago in an heroic effort.
      
      A different problem caused by this is that we cannot send the
      ASSOCREQIE/ASSOCRESPIE events because sending them causes a
      32-bit wpa_supplicant on a 64-bit system to overwrite its
      internal information, which is worse than it not getting the
      information at all -- so we currently resort to sending a
      custom string event that it then parses. This, however, has a
      severe size limitation we are frequently hitting with modern
      access points; this limitation would can be lifted after this
      patch by sending the correct binary, not custom, event.
      
      A similar problem apparently happens for some other netlink
      users on x86_64 with 32-bit tasks due to the alignment for
      64-bit quantities.
      
      In order to fix these problems, I have implemented a way to
      send compat messages to tasks. When sending an event, we send
      the non-compat event data together with a compat event data in
      skb_shinfo(main_skb)->frag_list. Then, when the event is read
      from the socket, the netlink code makes sure to pass out only
      the skb that is compatible with the task. This approach was
      suggested by David Miller, my original approach required
      always sending two skbs but that had various small problems.
      
      To determine whether compat is needed or not, I have used the
      MSG_CMSG_COMPAT flag, and adjusted the call path for recv and
      recvfrom to include it, even if those calls do not have a cmsg
      parameter.
      
      I have not solved one small part of the problem, and I don't
      think it is necessary to: if a 32-bit application uses read()
      rather than any form of recvmsg() it will still get the wrong
      (64-bit) event. However, neither do applications actually do
      this, nor would it be a regression.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1dacc76d
    • J
      wext: optimise, comment and fix event sending · 4f45b2cd
      Johannes Berg 提交于
      The current function for sending events first allocates the
      event stream buffer, and then an skb to copy the event stream
      into. This can be done in one go. Also, the current function
      leaks kernel data to userspace in a 4 uninitialised bytes,
      initialise those explicitly. Finally also add a few useful
      comments, as opposed to the current comments.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f45b2cd
    • J
      wireless extensions: make netns aware · b333b3d2
      Johannes Berg 提交于
      This makes wireless extensions netns aware. The
      tasklet sending the events is converted to a work
      struct so that we can rtnl_lock() in it.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b333b3d2
  13. 11 7月, 2009 2 次提交
  14. 23 5月, 2009 1 次提交
  15. 21 5月, 2009 1 次提交
    • J
      wext: verify buffer size for SIOCSIWENCODEEXT · 88f16db7
      Johannes Berg 提交于
      Another design flaw in wireless extensions (is anybody
      surprised?) in the way it handles the iw_encode_ext
      structure: The structure is part of the 'extra' memory
      but contains the key length explicitly, instead of it
      just being the length of the extra buffer - size of
      the struct and using the explicit key length only for
      the get operation (which only writes it).
      
      Therefore, we have this layout:
      
      extra: +-------------------------+
             | struct iw_encode_ext  { |
             |     ...                 |
             |     u16 key_len;        |
             |     u8 key[0];          |
             | };                      |
             +-------------------------+
             | key material            |
             +-------------------------+
      
      Now, all drivers I checked use ext->key_len without
      checking that both key_len and the struct fit into the
      extra buffer that has been copied from userspace. This
      leads to a buffer overrun while reading that buffer,
      depending on the driver it may be possible to specify
      arbitrary key_len or it may need to be a proper length
      for the key algorithm specified.
      
      Thankfully, this is only exploitable by root, but root
      can actually cause a segfault or use kernel memory as
      a key (which you can even get back with siocgiwencode
      or siocgiwencodeext from the key buffer).
      
      Fix this by verifying that key_len fits into the buffer
      along with struct iw_encode_ext.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      88f16db7
  16. 14 5月, 2009 1 次提交
  17. 12 5月, 2009 1 次提交
    • J
      wext: fix get_wireless_stats locking · 7be69c0b
      Johannes Berg 提交于
      Currently, get_wireless_stats is racy by _design_. This is
      because it returns a buffer, which needs to be statically
      allocated since it cannot be freed if it was allocated
      dynamically. Also, SIOCGIWSTATS and /proc/net/wireless use
      no common lock, and /proc/net/wireless accesses are not
      synchronised against each other. This is a design flaw in
      get_wireless_stats since the beginning.
      
      This patch fixes it by wrapping /proc/net/wireless accesses
      with the RTNL so they are protected against each other and
      SIOCGIWSTATS. The more correct method of fixing this would
      be to pass in the buffer instead of returning it and have
      the caller take care of synchronisation of the buffer, but
      even then most drivers probably assume that their callback
      is protected by the RTNL like all other wext callbacks.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7be69c0b
  18. 07 1月, 2009 1 次提交
  19. 07 12月, 2008 1 次提交
  20. 13 8月, 2008 1 次提交
  21. 20 7月, 2008 1 次提交
  22. 17 6月, 2008 10 次提交
  23. 26 3月, 2008 1 次提交
  24. 29 1月, 2008 3 次提交