1. 06 2月, 2017 3 次提交
  2. 24 1月, 2017 1 次提交
  3. 13 1月, 2017 2 次提交
    • M
      mac80211: prevent skb/txq mismatch · dbef5362
      Michal Kazior 提交于
      Station structure is considered as not uploaded
      (to driver) until drv_sta_state() finishes. This
      call is however done after the structure is
      attached to mac80211 internal lists and hashes.
      This means mac80211 can lookup (and use) station
      structure before it is uploaded to a driver.
      
      If this happens (structure exists, but
      sta->uploaded is false) fast_tx path can still be
      taken. Deep in the fastpath call the sta->uploaded
      is checked against to derive "pubsta" argument for
      ieee80211_get_txq(). If sta->uploaded is false
      (and sta is actually non-NULL) ieee80211_get_txq()
      effectively downgraded to vif->txq.
      
      At first glance this may look innocent but coerces
      mac80211 into a state that is almost guaranteed
      (codel may drop offending skb) to crash because a
      station-oriented skb gets queued up on
      vif-oriented txq. The ieee80211_tx_dequeue() ends
      up looking at info->control.flags and tries to use
      txq->sta which in the fail case is NULL.
      
      It's probably pointless to pretend one can
      downgrade skb from sta-txq to vif-txq.
      
      Since downgrading unicast traffic to vif->txq must
      not be done there's no txq to put a frame on if
      sta->uploaded is false. Therefore the code is made
      to fall back to regular tx() op path if the
      described condition is hit.
      
      Only drivers using wake_tx_queue were affected.
      
      Example crash dump before fix:
      
       Unable to handle kernel paging request at virtual address ffffe26c
       PC is at ieee80211_tx_dequeue+0x204/0x690 [mac80211]
       [<bf4252a4>] (ieee80211_tx_dequeue [mac80211]) from
       [<bf4b1388>] (ath10k_mac_tx_push_txq+0x54/0x1c0 [ath10k_core])
       [<bf4b1388>] (ath10k_mac_tx_push_txq [ath10k_core]) from
       [<bf4bdfbc>] (ath10k_htt_txrx_compl_task+0xd78/0x11d0 [ath10k_core])
       [<bf4bdfbc>] (ath10k_htt_txrx_compl_task [ath10k_core])
       [<bf51c5a4>] (ath10k_pci_napi_poll+0x54/0xe8 [ath10k_pci])
       [<bf51c5a4>] (ath10k_pci_napi_poll [ath10k_pci]) from
       [<c0572e90>] (net_rx_action+0xac/0x160)
      Reported-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      dbef5362
    • F
      mac80211: initialize SMPS field in HT capabilities · 43071d8f
      Felix Fietkau 提交于
      ibss and mesh modes copy the ht capabilites from the band without
      overriding the SMPS state. Unfortunately the default value 0 for the
      SMPS field means static SMPS instead of disabled.
      
      This results in HT ibss and mesh setups using only single-stream rates,
      even though SMPS is not supposed to be active.
      
      Initialize SMPS to disabled for all bands on ieee80211_hw_register to
      ensure that the value is sane where it is not overriden with the real
      SMPS state.
      Reported-by: NElektra Wagenrad <onelektra@gmx.net>
      Signed-off-by: NFelix Fietkau <nbd@nbd.name>
      [move VHT TODO comment to a better place]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      43071d8f
  4. 11 1月, 2017 4 次提交
    • J
      mac80211: recalculate min channel width on VHT opmode changes · d2941df8
      Johannes Berg 提交于
      When an associated station changes its VHT operating mode this
      can/will affect the bandwidth it's using, and consequently we
      must recalculate the minimum bandwidth we need to use. Failure
      to do so can lead to one of two scenarios:
       1) we use a too high bandwidth, this is benign
       2) we use a too narrow bandwidth, causing rate control and
          actual PHY configuration to be out of sync, which can in
          turn cause problems/crashes
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d2941df8
    • J
      mac80211: calculate min channel width correctly · 96aa2e7c
      Johannes Berg 提交于
      In the current minimum chandef code there's an issue in that the
      recalculation can happen after rate control is initialized for a
      station that has a wider bandwidth than the current chanctx, and
      then rate control can immediately start using those higher rates
      which could cause problems.
      
      Observe that first of all that this problem is because we don't
      take non-associated and non-uploaded stations into account. The
      restriction to non-associated is quite pointless and is one of
      the causes for the problem described above, since the rate init
      will happen before the station is set to associated; no frames
      could actually be sent until associated, but the rate table can
      already contain higher rates and that might cause problems.
      
      Also, rejecting non-uploaded stations is wrong, since the rate
      control can select higher rates for those as well.
      
      Secondly, it's then necessary to recalculate the minimal config
      before initializing rate control, so that when rate control is
      initialized, the higher rates are already available. This can be
      done easily by adding the necessary function call in rate init.
      
      Change-Id: Ib9bc02d34797078db55459d196993f39dcd43070
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      96aa2e7c
    • E
      mac80211: fix the TID on NDPs sent as EOSP carrier · d7f84244
      Emmanuel Grumbach 提交于
      In the commit below, I forgot to translate the mac80211's
      AC to QoS IE order. Moreover, the condition in the if was
      wrong. Fix both issues.
      This bug would hit only with clients that didn't set all
      the ACs as delivery enabled.
      
      Fixes: f438ceb8 ("mac80211: uapsd_queues is in QoS IE order")
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d7f84244
    • C
      mac80211: Fix headroom allocation when forwarding mesh pkt · c38c39bf
      Cedric Izoard 提交于
      This patch fix issue introduced by my previous commit that
      tried to ensure enough headroom was present, and instead
      broke it.
      
      When forwarding mesh pkt, mac80211 may also add security header,
      and it must therefore be taken into account in the needed headroom.
      
      Fixes: d8da0b5d ("mac80211: Ensure enough headroom when forwarding mesh pkt")
      Signed-off-by: NCedric Izoard <cedric.izoard@ceva-dsp.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c38c39bf
  5. 09 1月, 2017 1 次提交
    • J
      mac80211: implement multicast forwarding on fast-RX path · eeb0d56f
      Johannes Berg 提交于
      In AP (or VLAN) mode, when unicast 802.11 packets are received,
      they might actually be multicast after conversion. In this case
      the fast-RX path didn't handle them properly to send them back
      to the wireless medium. Implement that by copying the SKB and
      sending it back out.
      
      The possible alternative would be to just punt the packet back
      to the regular (slow) RX path, but since we have almost all of
      the required code here already it's not so complicated to add
      here. Punting it back would also mean acquiring the spinlock,
      which would be bad for the stated purpose of the fast-RX path,
      to enable well-performing parallel RX.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      eeb0d56f
  6. 02 1月, 2017 1 次提交
    • J
      mac80211: initialize fast-xmit 'info' later · 35f432a0
      Johannes Berg 提交于
      In ieee80211_xmit_fast(), 'info' is initialized to point to the skb
      that's passed in, but that skb may later be replaced by a clone (if
      it was shared), leading to an invalid pointer.
      
      This can lead to use-after-free and also later crashes since the
      real SKB's info->hw_queue doesn't get initialized properly.
      
      Fix this by assigning info only later, when it's needed, after the
      skb replacement (may have) happened.
      
      Cc: stable@vger.kernel.org
      Reported-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      35f432a0
  7. 16 12月, 2016 2 次提交
  8. 15 12月, 2016 1 次提交
  9. 13 12月, 2016 2 次提交
  10. 09 12月, 2016 1 次提交
    • J
      cfg80211/mac80211: fix BSS leaks when abandoning assoc attempts · e6f462df
      Johannes Berg 提交于
      When mac80211 abandons an association attempt, it may free
      all the data structures, but inform cfg80211 and userspace
      about it only by sending the deauth frame it received, in
      which case cfg80211 has no link to the BSS struct that was
      used and will not cfg80211_unhold_bss() it.
      
      Fix this by providing a way to inform cfg80211 of this with
      the BSS entry passed, so that it can clean up properly, and
      use this ability in the appropriate places in mac80211.
      
      This isn't ideal: some code is more or less duplicated and
      tracing is missing. However, it's a fairly small change and
      it's thus easier to backport - cleanups can come later.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e6f462df
  11. 15 11月, 2016 5 次提交
  12. 28 10月, 2016 1 次提交
    • A
      mac80211: fils_aead: fix encrypt error handling · 51487718
      Arnd Bergmann 提交于
      gcc -Wmaybe-uninitialized reports a bug in aes_siv_encryp:
      
      net/mac80211/fils_aead.c: In function ‘aes_siv_encrypt.constprop’:
      net/mac80211/fils_aead.c:84:26: error: ‘tfm2’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      At the time that the memory allocation fails, 'tfm2' has not been
      allocated, so we should not attempt to free it later, and we can
      simply return an error.
      
      Fixes: 39404fee ("mac80211: FILS AEAD protection for station mode association frames")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      51487718
  13. 27 10月, 2016 6 次提交
  14. 21 10月, 2016 1 次提交
    • J
      net: use core MTU range checking in wireless drivers · 9c22b4a3
      Jarod Wilson 提交于
      - set max_mtu in wil6210 driver
      - set max_mtu in atmel driver
      - set min/max_mtu in cisco airo driver, remove airo_change_mtu
      - set min/max_mtu in ipw2100/ipw2200 drivers, remove libipw_change_mtu
      - set min/max_mtu in p80211netdev, remove wlan_change_mtu
      - set min/max_mtu in net/mac80211/iface.c and remove ieee80211_change_mtu
      - set min/max_mtu in wimax/i2400m and remove i2400m_change_mtu
      - set min/max_mtu in intersil/hostap and remove prism2_change_mtu
      - set min/max_mtu in intersil/orinoco
      - set min/max_mtu in tty/n_gsm and remove gsm_change_mtu
      
      CC: netdev@vger.kernel.org
      CC: linux-wireless@vger.kernel.org
      CC: Maya Erez <qca_merez@qca.qualcomm.com>
      CC: Simon Kelley <simon@thekelleys.org.uk>
      CC: Stanislav Yakovlev <stas.yakovlev@gmail.com>
      CC: Johannes Berg <johannes@sipsolutions.net>
      CC: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9c22b4a3
  15. 19 10月, 2016 5 次提交
  16. 17 10月, 2016 3 次提交
  17. 13 10月, 2016 1 次提交