1. 24 3月, 2010 2 次提交
  2. 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
  3. 30 11月, 2009 1 次提交
  4. 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
  5. 29 9月, 2009 2 次提交
  6. 05 8月, 2009 1 次提交
  7. 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
  8. 11 7月, 2009 2 次提交
  9. 23 5月, 2009 1 次提交
  10. 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
  11. 14 5月, 2009 1 次提交
  12. 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
  13. 07 1月, 2009 1 次提交
  14. 07 12月, 2008 1 次提交
  15. 13 8月, 2008 1 次提交
  16. 20 7月, 2008 1 次提交
  17. 17 6月, 2008 10 次提交
  18. 26 3月, 2008 1 次提交
  19. 29 1月, 2008 3 次提交
  20. 20 11月, 2007 1 次提交
    • D
      [WIRELESS] WEXT: Fix userspace corruption on 64-bit. · 0a06ea87
      David S. Miller 提交于
      On 64-bit systems sizeof(struct ifreq) is 8 bytes larger than
      sizeof(struct iwreq).
      
      For GET calls, the wireless extension code copies back into userspace
      using sizeof(struct ifreq) but userspace and elsewhere only allocates
      a "struct iwreq".  Thus, this copy writes past the end of the iwreq
      object and corrupts whatever sits after it in memory.
      
      Fix the copy_to_user() length.
      
      This particularly hurts the compat case because the wireless compat
      code uses compat_alloc_userspace() and right after this allocated
      buffer is the current bottom of the user stack, and that's what gets
      overwritten by the copy_to_user() call.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0a06ea87
  21. 11 10月, 2007 4 次提交
    • E
      [NET]: Fix race when opening a proc file while a network namespace is exiting. · 077130c0
      Eric W. Biederman 提交于
      The problem:  proc_net files remember which network namespace the are
      against but do not remember hold a reference count (as that would pin
      the network namespace).   So we currently have a small window where
      the reference count on a network namespace may be incremented when opening
      a /proc file when it has already gone to zero.
      
      To fix this introduce maybe_get_net and get_proc_net.
      
      maybe_get_net increments the network namespace reference count only if it is
      greater then zero, ensuring we don't increment a reference count after it
      has gone to zero.
      
      get_proc_net handles all of the magic to go from a proc inode to the network
      namespace instance and call maybe_get_net on it.
      
      PROC_NET the old accessor is removed so that we don't get confused and use
      the wrong helper function.
      
      Then I fix up the callers to use get_proc_net and handle the case case
      where get_proc_net returns NULL.  In that case I return -ENXIO because
      effectively the network namespace has already gone away so the files
      we are trying to access don't exist anymore.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Acked-by: NPaul E. McKenney <paulmck@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      077130c0
    • E
      [NET]: Make the device list and device lookups per namespace. · 881d966b
      Eric W. Biederman 提交于
      This patch makes most of the generic device layer network
      namespace safe.  This patch makes dev_base_head a
      network namespace variable, and then it picks up
      a few associated variables.  The functions:
      dev_getbyhwaddr
      dev_getfirsthwbytype
      dev_get_by_flags
      dev_get_by_name
      __dev_get_by_name
      dev_get_by_index
      __dev_get_by_index
      dev_ioctl
      dev_ethtool
      dev_load
      wireless_process_ioctl
      
      were modified to take a network namespace argument, and
      deal with it.
      
      vlan_ioctl_set and brioctl_set were modified so their
      hooks will receive a network namespace argument.
      
      So basically anthing in the core of the network stack that was
      affected to by the change of dev_base was modified to handle
      multiple network namespaces.  The rest of the network stack was
      simply modified to explicitly use &init_net the initial network
      namespace.  This can be fixed when those components of the network
      stack are modified to handle multiple network namespaces.
      
      For now the ifindex generator is left global.
      
      Fundametally ifindex numbers are per namespace, or else
      we will have corner case problems with migration when
      we get that far.
      
      At the same time there are assumptions in the network stack
      that the ifindex of a network device won't change.  Making
      the ifindex number global seems a good compromise until
      the network stack can cope with ifindex changes when
      you change namespaces, and the like.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      881d966b
    • E
      [NET]: Make /proc/net per network namespace · 457c4cbc
      Eric W. Biederman 提交于
      This patch makes /proc/net per network namespace.  It modifies the global
      variables proc_net and proc_net_stat to be per network namespace.
      The proc_net file helpers are modified to take a network namespace argument,
      and all of their callers are fixed to pass &init_net for that argument.
      This ensures that all of the /proc/net files are only visible and
      usable in the initial network namespace until the code behind them
      has been updated to be handle multiple network namespaces.
      
      Making /proc/net per namespace is necessary as at least some files
      in /proc/net depend upon the set of network devices which is per
      network namespace, and even more files in /proc/net have contents
      that are relevant to a single network namespace.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      457c4cbc
    • T
      [WIRELESS]: Use type safe netlink interface · 744b096e
      Thomas Graf 提交于
      Makes use of the type safe netlink interface and adds a warning
      if the message is too big for NLMSG_DEFAULT_SIZE to help debug.
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      744b096e