linux-toradex.git/net/mac80211, branch v4.9.71

mac80211: Fix addition of mesh configuration element

2017-12-20T09:07:17+00:00

commit 57629915d568c522ac1422df7bba4bee5b5c7a7c upstream.

The code was setting the capabilities byte to zero,
after it was already properly set previously. Fix it.

The bug was found while debugging hwsim mesh tests failures
that happened since the commit mentioned below.

Fixes: 76f43b4c0a93 ("mac80211: Remove invalid flag operations in mesh TSF synchronization")
Signed-off-by: Ilan Peer 
Reviewed-by: Masashi Honma 
Signed-off-by: Johannes Berg 
Cc: Richard Schütz 
Cc: Mathias Kretschmer 
Signed-off-by: Greg Kroah-Hartman

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

2017-12-09T21:01:53+00:00

[ Upstream commit 115865fa0826ed18ca04717cf72d0fe874c0fe7f ]

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 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mac80211: prevent skb/txq mismatch

2017-12-09T21:01:52+00:00

[ Upstream commit dbef53621116474bb883f76f0ba6b7640bc42332 ]

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 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mac80211: calculate min channel width correctly

2017-12-09T21:01:51+00:00

[ Upstream commit 96aa2e7cf126773b16c6c19b7474a8a38d3c707e ]

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 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mac80211: Suppress NEW_PEER_CANDIDATE event if no room

2017-11-30T08:39:13+00:00

[ Upstream commit 11197d006bcfabf0173a7820a163fcaac420d10e ]

Previously, kernel sends NEW_PEER_CANDIDATE event to user land even if
the found peer does not have any room to accept other peer. This causes
continuous connection trials.

Signed-off-by: Masashi Honma 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mac80211: Remove invalid flag operations in mesh TSF synchronization

2017-11-30T08:39:13+00:00

[ Upstream commit 76f43b4c0a9337af22827d78de4f2b8fd5328489 ]

mesh_sync_offset_adjust_tbtt() implements Extensible synchronization
framework ([1] 13.13.2 Extensible synchronization framework). It shall
not operate the flag "TBTT Adjusting subfield" ([1] 8.4.2.100.8 Mesh
Capability), since it is used only for MBCA ([1] 13.13.4 Mesh beacon
collision avoidance, see 13.13.4.4.3 TBTT scanning and adjustment
procedures for detail). So this patch remove the flag operations.

[1] IEEE Std 802.11 2012

Signed-off-by: Masashi Honma 
[remove adjusting_tbtt entirely, since it's now unused]
Signed-off-by: Johannes Berg 

Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

mac80211: don't compare TKIP TX MIC key in reinstall prevention

2017-11-18T10:22:24+00:00

commit cfbb0d90a7abb289edc91833d0905931f8805f12 upstream.

For the reinstall prevention, the code I had added compares the
whole key. It turns out though that iwlwifi firmware doesn't
provide the TKIP TX MIC key as it's not needed in client mode,
and thus the comparison will always return false.

For client mode, thus always zero out the TX MIC key part before
doing the comparison in order to avoid accepting the reinstall
of the key with identical encryption and RX MIC key, but not the
same TX MIC key (since the supplicant provides the real one.)

Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
Signed-off-by: Johannes Berg 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

mac80211: use constant time comparison with keys

2017-11-18T10:22:23+00:00

commit 2bdd713b92a9cade239d3c7d15205a09f556624d upstream.

Otherwise we risk leaking information via timing side channel.

Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
Signed-off-by: Jason A. Donenfeld 
Signed-off-by: Johannes Berg 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

mac80211: accept key reinstall without changing anything

2017-11-18T10:22:23+00:00

commit fdf7cb4185b60c68e1a75e61691c4afdc15dea0e upstream.

When a key is reinstalled we can reset the replay counters
etc. which can lead to nonce reuse and/or replay detection
being impossible, breaking security properties, as described
in the "KRACK attacks".

In particular, CVE-2017-13080 applies to GTK rekeying that
happened in firmware while the host is in D3, with the second
part of the attack being done after the host wakes up. In
this case, the wpa_supplicant mitigation isn't sufficient
since wpa_supplicant doesn't know the GTK material.

In case this happens, simply silently accept the new key
coming from userspace but don't take any action on it since
it's the same key; this keeps the PN replay counters intact.

Signed-off-by: Johannes Berg 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix power saving clients handling in iwlwifi

2017-10-21T15:21:34+00:00

[ Upstream commit d98937f4ea713d21e0fcc345919f86c877dd8d6f ]

iwlwifi now supports RSS and can't let mac80211 track the
PS state based on the Rx frames since they can come out of
order. iwlwifi is now advertising AP_LINK_PS, and uses
explicit notifications to teach mac80211 about the PS state
of the stations and the PS poll / uAPSD trigger frames
coming our way from the peers.

Because of that, the TIM stopped being maintained in
mac80211. I tried to fix this in commit c68df2e7be0c
("mac80211: allow using AP_LINK_PS with mac80211-generated TIM IE")
but that was later reverted by Felix in commit 6c18a6b4e799
("Revert "mac80211: allow using AP_LINK_PS with mac80211-generated TIM IE")
since it broke drivers that do not implement set_tim.

Since none of the drivers that set AP_LINK_PS have the
set_tim() handler set besides iwlwifi, I can bail out in
__sta_info_recalc_tim if AP_LINK_PS AND .set_tim is not
implemented.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman