1. 23 1月, 2015 1 次提交
    • J
      nl80211: fix per-station group key get/del and memory leak · 0fa7b391
      Johannes Berg 提交于
      In case userspace attempts to obtain key information for or delete a
      unicast key, this is currently erroneously rejected unless the driver
      sets the WIPHY_FLAG_IBSS_RSN flag. Apparently enough drivers do so it
      was never noticed.
      
      Fix that, and while at it fix a potential memory leak: the error path
      in the get_key() function was placed after allocating a message but
      didn't free it - move it to a better place. Luckily admin permissions
      are needed to call this operation.
      
      Cc: stable@vger.kernel.org
      Fixes: e31b8213 ("cfg80211/mac80211: allow per-station GTKs")
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      0fa7b391
  2. 12 12月, 2014 1 次提交
    • L
      nl80211: check matches array length before acessing it · f89f46cf
      Luciano Coelho 提交于
      If the userspace passes a malformed sched scan request (or a net
      detect wowlan configuration) by adding a NL80211_ATTR_SCHED_SCAN_MATCH
      attribute without any nested matchsets, a NULL pointer dereference
      will occur.  Fix this by checking that we do have matchsets in our
      array before trying to access it.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000024
      IP: [<ffffffffa002fd69>] nl80211_parse_sched_scan.part.67+0x6e9/0x900 [cfg80211]
      PGD 865c067 PUD 865b067 PMD 0
      Oops: 0002 [#1] SMP
      Modules linked in: iwlmvm(O) iwlwifi(O) mac80211(O) cfg80211(O) compat(O) [last unloaded: compat]
      CPU: 2 PID: 2442 Comm: iw Tainted: G           O   3.17.2 #31
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      task: ffff880013800790 ti: ffff880008d80000 task.ti: ffff880008d80000
      RIP: 0010:[<ffffffffa002fd69>]  [<ffffffffa002fd69>] nl80211_parse_sched_scan.part.67+0x6e9/0x900 [cfg80211]
      RSP: 0018:ffff880008d838d0  EFLAGS: 00010293
      RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: 000000000000143c RSI: 0000000000000000 RDI: ffff880008ee8dd0
      RBP: ffff880008d83948 R08: 0000000000000002 R09: 0000000000000019
      R10: ffff88001d1b3c40 R11: 0000000000000002 R12: ffff880019e85e00
      R13: 00000000fffffed4 R14: ffff880009757800 R15: 0000000000001388
      FS:  00007fa3b6d13700(0000) GS:ffff88003e200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000024 CR3: 0000000008670000 CR4: 00000000000006e0
      Stack:
       ffff880009757800 ffff880000000001 0000000000000000 ffff880008ee84e0
       0000000000000000 ffff880009757800 00000000fffffed4 ffff880008d83948
       ffffffff814689c9 ffff880009757800 ffff880008ee8000 0000000000000000
      Call Trace:
       [<ffffffff814689c9>] ? nla_parse+0xb9/0x120
       [<ffffffffa00306de>] nl80211_set_wowlan+0x75e/0x960 [cfg80211]
       [<ffffffff810bf3d5>] ? mark_held_locks+0x75/0xa0
       [<ffffffff8161a77b>] genl_family_rcv_msg+0x18b/0x360
       [<ffffffff810bf66d>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff8161a9d4>] genl_rcv_msg+0x84/0xc0
       [<ffffffff8161a950>] ? genl_family_rcv_msg+0x360/0x360
       [<ffffffff81618e79>] netlink_rcv_skb+0xa9/0xd0
       [<ffffffff81619458>] genl_rcv+0x28/0x40
       [<ffffffff816184a5>] netlink_unicast+0x105/0x180
       [<ffffffff8161886f>] netlink_sendmsg+0x34f/0x7a0
       [<ffffffff8105a097>] ? kvm_clock_read+0x27/0x40
       [<ffffffff815c644d>] sock_sendmsg+0x8d/0xc0
       [<ffffffff811a75c9>] ? might_fault+0xb9/0xc0
       [<ffffffff811a756e>] ? might_fault+0x5e/0xc0
       [<ffffffff815d5d26>] ? verify_iovec+0x56/0xe0
       [<ffffffff815c73e0>] ___sys_sendmsg+0x3d0/0x3e0
       [<ffffffff810a7be8>] ? sched_clock_cpu+0x98/0xd0
       [<ffffffff810611b4>] ? __do_page_fault+0x254/0x580
       [<ffffffff810bb39f>] ? up_read+0x1f/0x40
       [<ffffffff810611b4>] ? __do_page_fault+0x254/0x580
       [<ffffffff812146ed>] ? __fget_light+0x13d/0x160
       [<ffffffff815c7b02>] __sys_sendmsg+0x42/0x80
       [<ffffffff815c7b52>] SyS_sendmsg+0x12/0x20
       [<ffffffff81751f69>] system_call_fastpath+0x16/0x1b
      
      Fixes: ea73cbce ("nl80211: fix scheduled scan RSSI matchset attribute confusion")
      Cc: stable@vger.kernel.org [3.15+]
      Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f89f46cf
  3. 28 11月, 2014 2 次提交
  4. 27 11月, 2014 1 次提交
  5. 26 11月, 2014 1 次提交
  6. 25 11月, 2014 1 次提交
  7. 20 11月, 2014 7 次提交
  8. 10 11月, 2014 2 次提交
  9. 04 11月, 2014 2 次提交
  10. 31 10月, 2014 1 次提交
  11. 30 10月, 2014 1 次提交
  12. 27 10月, 2014 1 次提交
  13. 22 10月, 2014 1 次提交
    • J
      cfg80211: make WMM TSPEC support flag an nl80211 feature flag · 723e73ac
      Johannes Berg 提交于
      During the review of the corresponding wpa_supplicant patches we
      noticed that the only way for it to detect that this functionality
      is supported currently is to check for the command support. This
      can be misleading though, as the command was also designed to, in
      the future, support pure 802.11 TSPECs.
      
      Expose the WMM-TSPEC feature flag to nl80211 so later we can also
      expose an 802.11-TSPEC feature flag (if needed) to differentiate
      the two cases.
      
      Note: this change isn't needed in 3.18 as there's no driver there
      yet that supports the functionality at all.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      723e73ac
  14. 20 10月, 2014 2 次提交
  15. 09 10月, 2014 2 次提交
  16. 11 9月, 2014 6 次提交
  17. 05 9月, 2014 3 次提交
  18. 03 9月, 2014 1 次提交
  19. 26 8月, 2014 1 次提交
    • J
      cfg80211: clarify BSS probe response vs. beacon data · 0e227084
      Johannes Berg 提交于
      There are a few possible cases of where BSS data came from:
       1) only a beacon has been received
       2) only a probe response has been received
       3) the driver didn't report what it received (this happens when
          using cfg80211_inform_bss[_width]())
       4) both probe response and beacon data has been received
      
      Unfortunately, in the userspace API, a few things weren't there:
       a) there was no way to differentiate cases 1) and 4) above
          without comparing the data of the IEs
       b) the TSF was always from the last frame, instead of being
          exposed for beacon/probe response separately like IEs
      
      Fix this by
         i) exporting a new flag attribute that indicates whether or
            not probe response data has been received - this addresses (a)
        ii) exporting a BEACON_TSF attribute that holds the beacon's TSF
            if a beacon has been received
       iii) not exporting the beacon attributes in case (3) above as that
            would just lead userspace into thinking the data actually came
            from a beacon when that isn't clear
      
      To implement this, track inside the IEs struct whether or not it
      (definitely) came from a beacon.
      
      Reported-by: William Seto
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      0e227084
  20. 21 7月, 2014 1 次提交
  21. 26 6月, 2014 1 次提交
  22. 24 6月, 2014 1 次提交