1. 09 Nov, 2011 2 commits
  2. 08 Nov, 2011 1 commit
  3. 07 Nov, 2011 2 commits
  4. 14 Oct, 2011 1 commit
  5. 30 Sep, 2011 3 commits
  6. 27 Sep, 2011 5 commits
  7. 21 Sep, 2011 1 commit
    • Jouni Malinen's avatar
      cfg80211: Fix validation of AKM suites · 1b9ca027
      Jouni Malinen authored
      
      
      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: default avatarJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      1b9ca027
  8. 19 Sep, 2011 2 commits
  9. 14 Sep, 2011 1 commit
  10. 13 Sep, 2011 3 commits
  11. 26 Aug, 2011 1 commit
  12. 24 Aug, 2011 3 commits
  13. 12 Aug, 2011 3 commits
  14. 11 Aug, 2011 2 commits
  15. 10 Aug, 2011 2 commits
  16. 01 Aug, 2011 1 commit
  17. 20 Jul, 2011 1 commit
  18. 19 Jul, 2011 1 commit
  19. 15 Jul, 2011 3 commits
  20. 06 Jul, 2011 1 commit
    • Johannes Berg's avatar
      cfg80211/nl80211: support GTK rekey offload · e5497d76
      Johannes Berg authored
      
      
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e5497d76
  21. 05 Jul, 2011 1 commit
    • Luciano Coelho's avatar
      cfg80211: fix deadlock with rfkill/sched_scan by adding new mutex · c10841ca
      Luciano Coelho authored
      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: default avatarDuane Griffin <duaneg@dghda.com>
      Signed-off-by: default avatarLuciano Coelho <coelho@ti.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      c10841ca