linux-stable.git/net/mac80211, branch v3.16.64

mac80211: ignore NullFunc frames in the duplicate detection

2019-02-11T17:54:20+00:00

commit 990d71846a0b7281bd933c34d734e6afc7408e7e upstream.

NullFunc packets should never be duplicate just like
QoS-NullFunc packets.

We saw a client that enters / exits power save with
NullFunc frames (and not with QoS-NullFunc) despite the
fact that the association supports HT.
This specific client also re-uses a non-zero sequence number
for different NullFunc frames.
At some point, the client had to send a retransmission of
the NullFunc frame and we dropped it, leading to a
misalignment in the power save state.
Fix this by never consider a NullFunc frame as duplicate,
just like we do for QoS NullFunc frames.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201449

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
[bwh: Backported to 3.16: The condition for "should we check for duplication"
 is in ieee80211_rx_h_check() and is not inverted]
Signed-off-by: Ben Hutchings

mac80211: fix reordering of buffered broadcast packets

2019-02-11T17:54:20+00:00

commit 9ec1190d065998650fd9260dea8cf3e1f56c0e8c upstream.

If the buffered broadcast queue contains packets, letting new packets bypass
that queue can lead to heavy reordering, since the driver is probably throttling
transmission of buffered multicast packets after beacons.

Keep buffering packets until the buffer has been cleared (and no client
is in powersave mode).

Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg 
Signed-off-by: Ben Hutchings

mac80211: Clear beacon_int in ieee80211_do_stop

2019-02-11T17:53:56+00:00

commit 5c21e8100dfd57c806e833ae905e26efbb87840f upstream.

This fixes stale beacon-int values that would keep a netdev
from going up.

To reproduce:

Create two VAP on one radio.
vap1 has beacon-int 100, start it.
vap2 has beacon-int 240, start it (and it will fail
  because beacon-int mismatch).
reconfigure vap2 to have beacon-int 100 and start it.
  It will fail because the stale beacon-int 240 will be used
  in the ifup path and hostapd never gets a chance to set the
  new beacon interval.

Signed-off-by: Ben Greear 
Signed-off-by: Johannes Berg 
Signed-off-by: Ben Hutchings

mac80211: fix setting IEEE80211_KEY_FLAG_RX_MGMT for AP mode keys

2018-12-16T22:09:31+00:00

commit 211710ca74adf790b46ab3867fcce8047b573cd1 upstream.

key->sta is only valid after ieee80211_key_link, which is called later
in this function. Because of that, the IEEE80211_KEY_FLAG_RX_MGMT is
never set when management frame protection is enabled.

Fixes: e548c49e6dc6b ("mac80211: add key flag for management keys")
Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg 
Signed-off-by: Ben Hutchings

cfg80211: fix cfg80211_beacon_dup

2018-06-16T21:22:20+00:00

commit bee92d06157fc39d5d7836a061c7d41289a55797 upstream.

gcc-8 warns about some obviously incorrect code:

net/mac80211/cfg.c: In function 'cfg80211_beacon_dup':
net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]

From the context, I conclude that we want to copy from beacon into
new_beacon, as we do in the rest of the function.

Fixes: 73da7d5bab79 ("mac80211: add channel switch command and beacon callbacks")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Johannes Berg 
Signed-off-by: Ben Hutchings

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

2017-11-26T13:50:39+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 
Signed-off-by: Ben Hutchings

mac80211: use constant time comparison with keys

2017-11-26T13:50:39+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 
Signed-off-by: Ben Hutchings

mac80211: flush hw_roc_start work before cancelling the ROC

2017-11-26T13:50:31+00:00

commit 6e46d8ce894374fc135c96a8d1057c6af1fef237 upstream.

When HW ROC is supported it is possible that after the HW notified
that the ROC has started, the ROC was cancelled and another ROC was
added while the hw_roc_start worker is waiting on the mutex (since
cancelling the ROC and adding another one also holds the same mutex).
As a result, the hw_roc_start worker will continue to run after the
new ROC is added but before it is actually started by the HW.
This may result in notifying userspace that the ROC has started before
it actually does, or in case of management tx ROC, in an attempt to
tx while not on the right channel.

In addition, when the driver will notify mac80211 that the second ROC
has started, mac80211 will warn that this ROC has already been
notified.

Fix this by flushing the hw_roc_start work before cancelling an ROC.

Signed-off-by: Avraham Stern 
Signed-off-by: Luca Coelho 
Signed-off-by: Johannes Berg 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

mac80211: accept key reinstall without changing anything

2017-11-11T13:33:38+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 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

mac80211/wpa: use constant time memory comparison for MACs

2017-09-15T17:30:10+00:00

commit 98c67d187db7808b1f3c95f2110dd4392d034182 upstream.

Otherwise, we enable all sorts of forgeries via timing attack.

Signed-off-by: Jason A. Donenfeld 
Cc: Johannes Berg 
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Johannes Berg 
[bwh: Backported to 3.16: drop changes in
 ieee80211_crypto_aes_{cmac_256,mac}_decrypt()]
Signed-off-by: Ben Hutchings