1. 12 5月, 2009 2 次提交
    • 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 4 次提交