linux-stable.git/net/mac80211, branch v4.10.2

mac80211: Fix adding of mesh vendor IEs

2017-02-06T06:55:44+00:00

The function ieee80211_ie_split_vendor doesn't return 0 on errors. Instead
it returns any offset < ielen when WLAN_EID_VENDOR_SPECIFIC is found. The
return value in mesh_add_vendor_ies must therefore be checked against
ifmsh->ie_len and not 0. Otherwise all ifmsh->ie starting with
WLAN_EID_VENDOR_SPECIFIC will be rejected.

Fixes: 082ebb0c258d ("mac80211: fix mesh beacon format")
Signed-off-by: Thorsten Horstmann 
Signed-off-by: Mathias Kretschmer 
Signed-off-by: Simon Wunderlich 
[sven@narfation.org: Add commit message]
Signed-off-by: Sven Eckelmann 
Signed-off-by: Johannes Berg

mac80211: Allocate a sync skcipher explicitly for FILS AEAD

2017-02-06T06:42:47+00:00

The skcipher could have been of the async variant which may return from
skcipher_encrypt() with -EINPROGRESS after having queued the request.
The FILS AEAD implementation here does not have code for dealing with
that possibility, so allocate a sync cipher explicitly to avoid
potential issues with hardware accelerators.

This is based on the patch sent out by Ard.

Fixes: 39404feee691 ("mac80211: FILS AEAD protection for station mode association frames")
Reported-by: Ard Biesheuvel 
Signed-off-by: Jouni Malinen 
Signed-off-by: Johannes Berg

mac80211: Fix FILS AEAD protection in Association Request frame

2017-02-06T06:42:39+00:00

Incorrect num_elem parameter value (1 vs. 5) was used in the
aes_siv_encrypt() call. This resulted in only the first one of the five
AAD vectors to SIV getting included in calculation. This does not
protect all the contents correctly and would not interoperate with a
standard compliant implementation.

Fix this by using the correct number. A matching fix is needed in the AP
side (hostapd) to get FILS authentication working properly.

Fixes: 39404feee691 ("mac80211: FILS AEAD protection for station mode association frames")
Reported-by: Ard Biesheuvel 
Signed-off-by: Jouni Malinen 
Signed-off-by: Johannes Berg

mac80211: don't try to sleep in rate_control_rate_init()

2017-01-24T15:31:54+00:00

In my previous patch, I missed that rate_control_rate_init() is
called from some places that cannot sleep, so it cannot call
ieee80211_recalc_min_chandef(). Remove that call for now to fix
the context bug, we'll have to find a different way to fix the
minimum channel width issue.

Fixes: 96aa2e7cf126 ("mac80211: calculate min channel width correctly")
Reported-by: Xiaolong Ye (via lkp-robot) 
Signed-off-by: Johannes Berg

mac80211: prevent skb/txq mismatch

2017-01-13T13:47:21+00:00

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]
 [] (ieee80211_tx_dequeue [mac80211]) from
 [] (ath10k_mac_tx_push_txq+0x54/0x1c0 [ath10k_core])
 [] (ath10k_mac_tx_push_txq [ath10k_core]) from
 [] (ath10k_htt_txrx_compl_task+0xd78/0x11d0 [ath10k_core])
 [] (ath10k_htt_txrx_compl_task [ath10k_core])
 [] (ath10k_pci_napi_poll+0x54/0xe8 [ath10k_pci])
 [] (ath10k_pci_napi_poll [ath10k_pci]) from
 [] (net_rx_action+0xac/0x160)

Reported-by: Mohammed Shafi Shajakhan 
Signed-off-by: Michal Kazior 
Signed-off-by: Johannes Berg

mac80211: initialize SMPS field in HT capabilities

2017-01-13T10:31:26+00:00

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: Elektra Wagenrad 
Signed-off-by: Felix Fietkau 
[move VHT TODO comment to a better place]
Signed-off-by: Johannes Berg

mac80211: recalculate min channel width on VHT opmode changes

2017-01-11T15:35:05+00:00

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: Johannes Berg

mac80211: calculate min channel width correctly

2017-01-11T15:34:51+00:00

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: Johannes Berg

mac80211: fix the TID on NDPs sent as EOSP carrier

2017-01-11T15:32:58+00:00

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: f438ceb81d4 ("mac80211: uapsd_queues is in QoS IE order")
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg

mac80211: Fix headroom allocation when forwarding mesh pkt

2017-01-11T15:07:29+00:00

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: d8da0b5d64d5 ("mac80211: Ensure enough headroom when forwarding mesh pkt")
Signed-off-by: Cedric Izoard 
Signed-off-by: Johannes Berg