1. 02 Jun, 2015 3 commits
    • Johannes Berg's avatar
      mac80211: stop using pointers as userspace cookies · 3b79af97
      Johannes Berg authored
      Even if the pointers are really only accessible to root and used
      pretty much only by wpa_supplicant, this is still not great; even
      for debugging it'd be easier to have something that's easier to
      read and guaranteed to never get reused.
      
      With the recent change to make mac80211 create an ack_skb for the
      mgmt-tx path this becomes possible, only the client probe method
      needs to also allocate an ack_skb, and we can store the cookie in
      that skb.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3b79af97
    • Johannes Berg's avatar
      mac80211: copy nl80211 mgmt TX SKB for status · b2eb0ee6
      Johannes Berg authored
      When we return the TX status for an nl80211 mgmt TX SKB, we
      should also return the original frame with the status to
      allow userspace to match up the submission (it could also
      use the cookie but both ways are permissible.)
      
      As TX SKBs could be encrypted, at least in the case of ANQP
      while associated with the AP, copy the original SKB, store
      it with an ACK frame ID and restructure the status path to
      use that to return status with the original SKB. Otherwise,
      userspace (in particular wpa_supplicant) will get confused.
      Reported-by: default avatarMatti Gottlieb <matti.gottlieb@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      b2eb0ee6
    • Johannes Berg's avatar
      mac80211: move TX PN to public part of key struct · db388a56
      Johannes Berg authored
      For drivers supporting TSO or similar features, but that still have
      PN assignment in software, there's a need to have some memory to
      store the current PN value. As mac80211 already stores this and it's
      somewhat complicated to add a per-driver area to the key struct (due
      to the dynamic sizing thereof) it makes sense to just move the TX PN
      to the keyconf, i.e. the public part of the key struct.
      
      As TKIP is more complicated and we won't able to offload it in this
      way right now (fast-xmit is skipped for TKIP unless the HW does it
      all, and our hardware needs MMIC calculation in software) I've not
      moved that for now - it's possible but requires exposing a lot of
      the internal TKIP state.
      
      As an bonus side effect, we can remove a lot of code by assuming the
      keyseq struct has a certain layout - with BUILD_BUG_ON to verify it.
      
      This might also improve performance, since now TX and RX no longer
      share a cacheline.
      Reviewed-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      db388a56
  2. 01 Jun, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: act upon and report deauth while associating · c9c99f89
      Johannes Berg authored
      When trying to associate, the AP could send a deauth frame instead.
      Currently mac80211 drops that frame and doesn't report it to the
      supplicant, which, in some versions and/or in certain circumstances
      will simply keep trying to associate over and over again instead of
      trying authentication again.
      
      Fix this by reacting to deauth frames while associating, reporting
      them to the supplicant and dropping the association attempt (which
      is bound to fail.)
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      c9c99f89
  3. 29 May, 2015 3 commits
    • Uwe Kleine-König's avatar
      net: rfkill: gpio: make better use of gpiod API · f7959e9c
      Uwe Kleine-König authored
      Since 39b2bbe3 (gpio: add flags argument to gpiod_get*() functions)
      which appeared in v3.17-rc1, the gpiod_get* functions take an additional
      parameter that allows to specify direction and initial value for output.
      
      Furthermore there is devm_gpiod_get_optional which is designed to get
      optional gpios.
      
      Simplify driver accordingly.
      
      Note this makes error checking more strict because only -ENOENT is
      ignored when searching for the GPIOs which is good.
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f7959e9c
    • Michal Kazior's avatar
      cfg80211: ignore netif running state when changing iftype · 6cbfb1bb
      Michal Kazior authored
      It was possible for mac80211 to be coerced into an
      unexpected flow causing sdata union to become
      corrupted. Station pointer was put into
      sdata->u.vlan.sta memory location while it was
      really master AP's sdata->u.ap.next_beacon. This
      led to station entry being later freed as
      next_beacon before __sta_info_flush() in
      ieee80211_stop_ap() and a subsequent invalid
      pointer dereference crash.
      
      The problem was that ieee80211_ptr->use_4addr
      wasn't cleared on interface type changes.
      
      This could be reproduced with the following steps:
      
       # host A and host B have just booted; no
       # wpa_s/hostapd running; all vifs are down
       host A> iw wlan0 set type station
       host A> iw wlan0 set 4addr on
       host A> printf 'interface=wlan0\nssid=4addrcrash\nchannel=1\nwds_sta=1' > /tmp/hconf
       host A> hostapd -B /tmp/conf
       host B> iw wlan0 set 4addr on
       host B> ifconfig wlan0 up
       host B> iw wlan0 connect -w hostAssid
       host A> pkill hostapd
       # host A crashed:
      
       [  127.928192] BUG: unable to handle kernel NULL pointer dereference at 00000000000006c8
       [  127.929014] IP: [<ffffffff816f4f32>] __sta_info_flush+0xac/0x158
       ...
       [  127.934578]  [<ffffffff8170789e>] ieee80211_stop_ap+0x139/0x26c
       [  127.934578]  [<ffffffff8100498f>] ? dump_trace+0x279/0x28a
       [  127.934578]  [<ffffffff816dc661>] __cfg80211_stop_ap+0x84/0x191
       [  127.934578]  [<ffffffff816dc7ad>] cfg80211_stop_ap+0x3f/0x58
       [  127.934578]  [<ffffffff816c5ad6>] nl80211_stop_ap+0x1b/0x1d
       [  127.934578]  [<ffffffff815e53f8>] genl_family_rcv_msg+0x259/0x2b5
      
      Note: This isn't a revert of f8cdddb8
      ("cfg80211: check iface combinations only when
      iface is running") as far as functionality is
      considered because b6a55015 ("cfg80211/mac80211:
      move more combination checks to mac80211") moved
      the logic somewhere else already.
      
      Fixes: f8cdddb8 ("cfg80211: check iface combinations only when iface is running")
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      6cbfb1bb
    • Michal Kazior's avatar
      mac80211: prevent possible crypto tx tailroom corruption · ab499db8
      Michal Kazior authored
      There was a possible race between
      ieee80211_reconfig() and
      ieee80211_delayed_tailroom_dec(). This could
      result in inability to transmit data if driver
      crashed during roaming or rekeying and subsequent
      skbs with insufficient tailroom appeared.
      
      This race was probably never seen in the wild
      because a device driver would have to crash AND
      recover within 0.5s which is very unlikely.
      
      I was able to prove this race exists after
      changing the delay to 10s locally and crashing
      ath10k via debugfs immediately after GTK
      rekeying. In case of ath10k the counter went below
      0. This was harmless but other drivers which
      actually require tailroom (e.g. for WEP ICV or
      MMIC) could end up with the counter at 0 instead
      of >0 and introduce insufficient skb tailroom
      failures because mac80211 would not resize skbs
      appropriately anymore.
      
      Fixes: 8d1f7ecd ("mac80211: defer tailroom counter manipulation when roaming")
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      ab499db8
  4. 26 May, 2015 1 commit
    • Johannes Berg's avatar
      cfg80211: properly send NL80211_ATTR_DISCONNECTED_BY_AP in disconnect · 80279fb7
      Johannes Berg authored
      When we disconnect from the AP, drivers call cfg80211_disconnect().
      This doesn't know whether the disconnection was initiated locally
      or by the AP though, which can cause problems with the supplicant,
      for example with WPS. This issue obviously doesn't show up with any
      mac80211 based driver since mac80211 doesn't call this function.
      
      Fix this by requiring drivers to indicate whether the disconnect is
      locally generated or not. I've tried to update the drivers, but may
      not have gotten the values correct, and some drivers may currently
      not be able to report correct values. In case of doubt I left it at
      false, which is the current behaviour.
      
      For libertas, make adjustments as indicated by Dan Williams.
      Reported-by: default avatarMatthieu Mauger <matthieux.mauger@intel.com>
      Tested-by: default avatarMatthieu Mauger <matthieux.mauger@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      80279fb7
  5. 20 May, 2015 6 commits
  6. 11 May, 2015 3 commits
  7. 07 May, 2015 1 commit
  8. 06 May, 2015 8 commits
  9. 05 May, 2015 7 commits
  10. 24 Apr, 2015 7 commits