xavi/android_kernel_m2note/net/mac80211, branch ng-7.1.2

mac80211: ignore NullFunc frames in the duplicate detection

2019-05-03T17:26:16+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 Change-Id: I524be05ea82cf34826ed826ac26e264968198a2c 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-05-03T17:26:01+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). Change-Id: I7ef15c9540c4300a29ffd27754b25fd02afbf34f Signed-off-by: Felix Fietkau Signed-off-by: Johannes Berg Signed-off-by: Ben Hutchings

mac80211: always send multicast on CAB queue

2019-05-03T17:25:45+00:00

If the driver advertised support for a CAB queue, then we should put all multicast frames there, otherwise sending them can be racy with clients going to sleep while we TX a frame. To avoid this, always TX multicast frames on the multicast queue. It seems like even drivers not using the queue framework might want to do this which would mean also moving the IEEE80211_TX_CTL_SEND_AFTER_DTIM flag assignment, but it also seems that drivers behave differently here so that just moving it wouldn't be a good idea. It'd be better to modify those drivers to use the queue framework. Change-Id: I7993bfb8af3ab67564698d6ff64136d976ff671f Signed-off-by: Johannes Berg

mac80211: Clear beacon_int in ieee80211_do_stop

2019-05-03T17:25:24+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. Change-Id: I7df2ed6b79762f95f29123a1d1296c514d895216 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

2019-05-03T17:24:03+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") Change-Id: I68369a1a0ed2646246f47bf1cb286e51e0538d0a Signed-off-by: Felix Fietkau Signed-off-by: Johannes Berg Signed-off-by: Ben Hutchings

mac80211: use constant time comparison with keys

2017-10-20T15:42:47+00:00

Otherwise we risk leaking information via timing side channel. Change-Id: I777afd16f7b0ca8a5ab1b95ddc66689afdc96636 Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything") Signed-off-by: Jason A. Donenfeld Signed-off-by: Johannes Berg Signed-off-by: Moyster

mac80211: accept key reinstall without changing anything

2017-10-20T15:42:17+00:00

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. Change-Id: I7576ed8c8df85a767ebf15e74a642063eb34d0f5 Signed-off-by: Johannes Berg Signed-off-by: Moyster

mac80211: flush delayed work when entering suspend

2017-07-04T09:51:38+00:00

commit a9e9200d8661c1a0be8c39f93deb383dc940de35 upstream. The issue was found when entering suspend and resume. It triggers a warning in: mac80211/key.c: ieee80211_enable_keys() ... WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt || sdata->crypto_tx_tailroom_pending_dec); ... It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully in a delayed_work during suspend. Add a flush_delayed_work to fix it. Signed-off-by: Matt Chen Signed-off-by: Johannes Berg Signed-off-by: Willy Tarreau

mac80211: Fix adding of mesh vendor IEs

2017-06-17T13:51:02+00:00

commit da7061c82e4a1bc6a5e134ef362c86261906c860 upstream. 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 Signed-off-by: Willy Tarreau

mac80211: discard multicast and 4-addr A-MSDUs

2017-04-11T08:58:47+00:00

commit ea720935cf6686f72def9d322298bf7e9bd53377 upstream. In mac80211, multicast A-MSDUs are accepted in many cases that they shouldn't be accepted in: * drop A-MSDUs with a multicast A1 (RA), as required by the spec in 9.11 (802.11-2012 version) * drop A-MSDUs with a 4-addr header, since the fourth address can't actually be useful for them; unless 4-address frame format is actually requested, even though the fourth address is still not useful in this case, but ignored Accepting the first case, in particular, is very problematic since it allows anyone else with possession of a GTK to send unicast frames encapsulated in a multicast A-MSDU, even when the AP has client isolation enabled. Signed-off-by: Johannes Berg Signed-off-by: Willy Tarreau