1. 10 11月, 2011 1 次提交
  2. 09 11月, 2011 1 次提交
  3. 08 11月, 2011 2 次提交
  4. 15 10月, 2011 1 次提交
  5. 01 10月, 2011 3 次提交
  6. 28 9月, 2011 5 次提交
  7. 22 9月, 2011 1 次提交
    • J
      cfg80211: Fix validation of AKM suites · 1b9ca027
      Jouni Malinen 提交于
      Incorrect variable was used in validating the akm_suites array from
      NL80211_ATTR_AKM_SUITES. In addition, there was no explicit
      validation of the array length (we only have room for
      NL80211_MAX_NR_AKM_SUITES).
      
      This can result in a buffer write overflow for stack variables with
      arbitrary data from user space. The nl80211 commands using the affected
      functionality require GENL_ADMIN_PERM, so this is only exposed to admin
      users.
      
      Cc: stable@kernel.org
      Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1b9ca027
  8. 20 9月, 2011 2 次提交
  9. 15 9月, 2011 1 次提交
  10. 14 9月, 2011 3 次提交
  11. 26 8月, 2011 1 次提交
  12. 25 8月, 2011 3 次提交
  13. 13 8月, 2011 3 次提交
  14. 12 8月, 2011 2 次提交
  15. 11 8月, 2011 2 次提交
  16. 02 8月, 2011 1 次提交
  17. 21 7月, 2011 1 次提交
  18. 20 7月, 2011 1 次提交
  19. 16 7月, 2011 3 次提交
  20. 07 7月, 2011 1 次提交
    • J
      cfg80211/nl80211: support GTK rekey offload · e5497d76
      Johannes Berg 提交于
      In certain circumstances, like WoWLAN scenarios,
      devices may implement (partial) GTK rekeying on
      the device to avoid waking up the host for it.
      
      In order to successfully go through GTK rekeying,
      the KEK, KCK and the replay counter are required.
      
      Add API to let the supplicant hand the parameters
      to the driver which may store it for future GTK
      rekey operations.
      
      Note that, of course, if GTK rekeying is done by
      the device, the EAP frame must not be passed up
      to userspace, instead a rekey event needs to be
      sent to let userspace update its replay counter.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e5497d76
  21. 06 7月, 2011 1 次提交
    • L
      cfg80211: fix deadlock with rfkill/sched_scan by adding new mutex · c10841ca
      Luciano Coelho 提交于
      There was a deadlock when rfkill-blocking a wireless interface,
      because we were locking the rdev mutex on NETDEV_GOING_DOWN to stop
      sched_scans that were eventually running.  The rfkill block code was
      already holding a mutex under rdev:
      
      kernel: =======================================================
      kernel: [ INFO: possible circular locking dependency detected ]
      kernel: 3.0.0-rc1-00049-g1fa7b6a2 #57
      kernel: -------------------------------------------------------
      kernel: kworker/0:1/4525 is trying to acquire lock:
      kernel: (&rdev->mtx){+.+.+.}, at: [<ffffffff8164c831>] cfg80211_netdev_notifier_call+0x131/0x5b0
      kernel:
      kernel: but task is already holding lock:
      kernel: (&rdev->devlist_mtx){+.+.+.}, at: [<ffffffff8164dcef>] cfg80211_rfkill_set_block+0x4f/0xa0
      kernel:
      kernel: which lock already depends on the new lock.
      
      To fix this, add a new mutex specifically for sched_scan, to protect
      the sched_scan_req element in the rdev struct, instead of using the
      global rdev mutex.
      Reported-by: NDuane Griffin <duaneg@dghda.com>
      Signed-off-by: NLuciano Coelho <coelho@ti.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c10841ca
  22. 28 6月, 2011 1 次提交