1. 12 5月, 2009 5 次提交
    • 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
    • J
      cfg80211: disallow interfering with stations on non-AP · e80cf853
      Johannes Berg 提交于
      On non-AP interfaces userspace has no business interfering with
      the station management, this can confuse mac80211 (and other
      drivers probably wouldn't support it anyway). Allow adding and
      removing stations only on AP interfaces.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e80cf853
    • J
      cfg80211: put wext data into substructure · cbe8fa9c
      Johannes Berg 提交于
      To make it more apparent in the code what is for wext
      only (and needs to be #ifdef'ed) put all the info for
      wext into a substruct in each wireless_dev.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cbe8fa9c
    • J
      cfg80211: fix wext iw_freq parsing · 0b258582
      Johannes Berg 提交于
      The function to parse a struct iw_freq has a stupid bug,
      it returns NULL when the channel cannot be found at all,
      but NULL is supposed to mean "auto". Fix this by checking
      the return value of ieee80211_get_channel() and returning
      ERR_PTR(-EINVAL) if it returned NULL (channel not found).
      
      This fixes an issue where you could say (in IBSS mode)
      	iwconfig wlan0 channel 21
      and it would use channel 1 instead because that's the
      first available channel with IBSS allowed (which is what
      the "auto" setting uses).
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0b258582
    • J
      nl80211 : Add support for configuring MFP · dc6382ce
      Jouni Malinen 提交于
      NL80211_CMD_ASSOCIATE request must be able to indicate whether
      management frame protection (IEEE 802.11w) is being used. mac80211 was
      able to use MFP in client mode only with WEXT, but the new
      NL80211_ATTR_USE_MFP attribute will allow this to be done with
      nl80211, too.
      
      Since we are currently using nl80211 for MFP only with drivers that
      use user space SME, only MFP disabled and required values are
      used. However, the NL80211_ATTR_USE_MFP attribute is an enum that can
      be extended with MFP optional in the future, if that is needed with
      some drivers (e.g., if the RSN IE is generated by the driver).
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      dc6382ce
  2. 07 5月, 2009 4 次提交
  3. 05 5月, 2009 4 次提交
    • L
    • L
      cfg80211: fix bug while trying to process beacon hints on init · b1ed8ddd
      Luis R. Rodriguez 提交于
      During initialization we would not have received any beacons
      so skip processing reg beacon hints, also adds a check to
      reg_is_world_roaming() for last_request before accessing its
      fields.
      
      This should fix this:
      
      BUG: unable to handle kernel NULL pointer dereference at
      
      IP: [<e0171332>] wiphy_update_regulatory+0x20f/0x295
      
      *pdpt = 0000000008bf1001 *pde = 0000000000000000
      Oops: 0000 [#1]
      last sysfs file: /sys/class/backlight/eeepc/brightness
      Modules linked in: ath5k(+) mac80211 led_class cfg80211
      go_bit cfbcopyarea cfbimgblt cfbfillrect ipv6
      ydev usual_tables(P) snd_hda_codec_realtek snd_hda_intel
      nd_hwdep uhci_hcd snd_pcm_oss snd_mixer_oss i2c_i801
      e serio_raw i2c_core pcspkr atl2 snd_pcm intel_agp
      re agpgart eeepc_laptop snd_page_alloc ac video backlight
      rfkill button processor evdev thermal fan ata_generic
      
      Pid: 2909, comm: modprobe Tainted: Pc #112) 701
      EIP: 0060:[<e0171332>] EFLAGS: 00010246 CPU: 0
      EIP is at wiphy_update_regulatory+0x20f/0x295 [cfg80211]
      EAX: 00000000 EBX: c5da0000 ECX: 00000000 EDX: c5da0060
      ESI: 0000001a EDI: c5da0060 EBP: df3bdd70 ESP: df3bdd40
       DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
      Process modprobe (pid: 2909, ti=df3bc000 task=c5d030000)
      Stack:
       df3bdd90 c5da0060 c04277e0 00000001 00000044 c04277e402
       00000002 c5da0000 0000001a c5da0060 df3bdda8 e01706a2 02
       00000282 000080d0 00000068 c5d53500 00000080 0000028240
      Call Trace:
       [<e01706a2>] ? wiphy_register+0x122/0x1b7 [cfg80211]
       [<e0328e02>] ? ieee80211_register_hw+0xd8/0x346
       [<e06a7c9f>] ? ath5k_hw_set_bssid_mask+0x71/0x78 [ath5k]
       [<e06b0c52>] ? ath5k_pci_probe+0xa5c/0xd0a [ath5k]
       [<c01a6037>] ? sysfs_find_dirent+0x16/0x27
       [<c01fec95>] ? local_pci_probe+0xe/0x10
       [<c01ff526>] ? pci_device_probe+0x48/0x66
       [<c024c9fd>] ? driver_probe_device+0x7f/0xf2
       [<c024cab3>] ? __driver_attach+0x43/0x5f
       [<c024c0af>] ? bus_for_each_dev+0x39/0x5a
       [<c024c8d0>] ? driver_attach+0x14/0x16
       [<c024ca70>] ? __driver_attach+0x0/0x5f
       [<c024c5b3>] ? bus_add_driver+0xd7/0x1e7
       [<c024ccb9>] ? driver_register+0x7b/0xd7
       [<c01ff827>] ? __pci_register_driver+0x32/0x85
       [<e00a8018>] ? init_ath5k_pci+0x18/0x30 [ath5k]
       [<c0101131>] ? _stext+0x49/0x10b
       [<e00a8000>] ? init_ath5k_pci+0x0/0x30 [ath5k]
       [<c012f452>] ? __blocking_notifier_call_chain+0x40/0x4c
       [<c013a714>] ? sys_init_module+0x87/0x18b
       [<c0102804>] ? sysenter_do_call+0x12/0x22
      Code: b8 da 17 e0 83 c0 04 e8 92 f9 ff ff 84 c0 75 2a 8b
      85 c0 74 0c 83 c0 04 e8 7c f9 ff ff 84 c0 75 14 a1 bc da
      4 03 74 66 8b 4d d4 80 79 08 00 74 5d a1 e0 d2 17 e0 48
      EIP: [<e0171332>] wiphy_update_regulatory+0x20f/0x295
      SP 0068:df3bdd40
      CR2: 0000000000000004
      ---[ end trace 830f2dd2a95fd1a8 ]---
      
      This issue is hard to reproduce, but it was noticed and discussed on
      this thread:
      
      http://marc.info/?t=123938022700005&r=1&w=2
      
      Cc: stable@kernel.org
      Reported-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b1ed8ddd
    • L
      cfg80211: fix race condition with wiphy_apply_custom_regulatory() · ac46d48e
      Luis R. Rodriguez 提交于
      We forgot to lock using the cfg80211_mutex in
      wiphy_apply_custom_regulatory(). Without the lock
      there is possible race between processing a reply from CRDA
      and a driver calling wiphy_apply_custom_regulatory(). During
      the processing of the reply from CRDA we free last_request and
      wiphy_apply_custom_regulatory() eventually accesses an
      element from last_request in the through freq_reg_info_regd().
      
      This is very difficult to reproduce (I haven't), it takes us
      3 hours and you need to be banging hard, but the race is obvious
      by looking at the code.
      
      This should only affect those who use this caller, which currently
      is ath5k, ath9k, and ar9170.
      
      EIP: 0060:[<f8ebec50>] EFLAGS: 00210282 CPU: 1
      EIP is at freq_reg_info_regd+0x24/0x121 [cfg80211]
      EAX: 00000000 EBX: f7ca0060 ECX: f5183d94 EDX: 0024cde0
      ESI: f8f56edc EDI: 00000000 EBP: 00000000 ESP: f5183d44
      DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      Process modprobe (pid: 14617, ti=f5182000 task=f3934d10 task.ti=f5182000)
      Stack: c0505300 f7ca0ab4 f5183d94 0024cde0 f8f403a6 f8f63160 f7ca0060 00000000
      00000000 f8ebedf8 f5183d90 f8f56edc 00000000 00000004 00000f40 f8f56edc
      f7ca0060 f7ca1234 00000000 00000000 00000000 f7ca14f0 f7ca0ab4 f7ca1289
      Call Trace:
      [<f8ebedf8>] wiphy_apply_custom_regulatory+0x8f/0x122 [cfg80211]
      [<f8f3f798>] ath_attach+0x707/0x9e6 [ath9k]
      [<f8f45e46>] ath_pci_probe+0x18d/0x29a [ath9k]
      [<c023c7ba>] pci_device_probe+0xa3/0xe4
      [<c02a860b>] really_probe+0xd7/0x1de
      [<c02a87e7>] __driver_attach+0x37/0x55
      [<c02a7eed>] bus_for_each_dev+0x31/0x57
      [<c02a83bd>] driver_attach+0x16/0x18
      [<c02a78e6>] bus_add_driver+0xec/0x21b
      [<c02a8959>] driver_register+0x85/0xe2
      [<c023c9bb>] __pci_register_driver+0x3c/0x69
      [<f8e93043>] ath9k_init+0x43/0x68 [ath9k]
      [<c010112b>] _stext+0x3b/0x116
      [<c014a872>] sys_init_module+0x8a/0x19e
      [<c01049ad>] sysenter_do_call+0x12/0x21
      [<ffffe430>] 0xffffe430
      =======================
      Code: 0f 94 c0 c3 31 c0 c3 55 57 56 53 89 c3 83 ec 14 8b 74 24 2c 89 54 24 0c 89 4c 24 08 85 f6 75
      06 8b 35 c8 bb ec f8 a1 cc bb ec f8 <8b> 40 04 83 f8 03 74 3a 48 74 37 8b 43 28 85 c0 74 30 89 c6
      8b
      EIP: [<f8ebec50>] freq_reg_info_regd+0x24/0x121 [cfg80211] SS:ESP 0068:f5183d44
      
      Cc: stable@kernel.org
      Reported-by: NNataraj Sadasivam <Nataraj.Sadasivam@Atheros.com>
      Reported-by: NVivek Natarajan <Vivek.Natarajan@Atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ac46d48e
    • J
      cfg80211: fix truncated IEs · c0f0aac0
      Johannes Berg 提交于
      Another bug in the "cfg80211: do not replace BSS structs" patch,
      a forgotten length update leads to bogus data being stored and
      passed to userspace, often truncated.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c0f0aac0
  4. 23 4月, 2009 22 次提交
  5. 21 4月, 2009 1 次提交
  6. 18 4月, 2009 2 次提交
  7. 16 4月, 2009 1 次提交
  8. 28 3月, 2009 1 次提交