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

mac80211: RX BA support for sta max_rx_aggregation_subframes

2017-05-20T12:27:03+00:00

commit 480dd46b9d6812e5fb7172c305ee0f1154c26eed upstream.

The ability to change the max_rx_aggregation frames is useful
in cases of IOP.

There exist some devices (latest mobile phones and some AP's)
that tend to not respect a BA sessions maximum size (in Kbps).
These devices won't respect the AMPDU size that was negotiated during
association (even though they do respect the maximal number of packets).

This violation is characterized by a valid number of packets in
a single AMPDU. Even so, the total size will exceed the size negotiated
during association.

Eventually, this will cause some undefined behavior, which in turn
causes the hw to drop packets, causing the throughput to plummet.

This patch will make the subframe limitation to be held by each station,
instead of being held only by hw.

Signed-off-by: Maxim Altshul 
Signed-off-by: Johannes Berg 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

mac80211: pass block ack session timeout to to driver

2017-05-20T12:27:03+00:00

commit 50ea05efaf3bed7dd34bcc2635a8b3f53bd0ccc1 upstream.

Currently mac80211 does not inform the driver of the session
block ack timeout when starting a rx aggregation session.
Drivers that manage the reorder buffer need to know this
parameter.
Seeing that there are now too many arguments for the
drv_ampdu_action() function, wrap them inside a structure.

Signed-off-by: Sara Sharon 
Signed-off-by: Johannes Berg 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

mac80211: pass RX aggregation window size to driver

2017-05-20T12:27:02+00:00

commit fad471860c097844432c7cf5d3ae6a0a059c2bdc upstream.

Currently mac80211 does not inform the driver of the window
size when starting an RX aggregation session.
To enable managing the reorder buffer in the driver or hardware
the window size is needed.

Signed-off-by: Sara Sharon 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

mac80211: reject ToDS broadcast data frames

2017-04-27T07:09:33+00:00

commit 3018e947d7fd536d57e2b550c33e456d921fff8c upstream.

AP/AP_VLAN modes don't accept any real 802.11 multicast data
frames, but since they do need to accept broadcast management
frames the same is currently permitted for data frames. This
opens a security problem because such frames would be decrypted
with the GTK, and could even contain unicast L3 frames.

Since the spec says that ToDS frames must always have the BSSID
as the RA (addr1), reject any other data frames.

The problem was originally reported in "Predicting, Decrypting,
and Abusing WPA2/802.11 Group Keys" at usenix
https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/vanhoef
and brought to my attention by Jouni.

Reported-by: Jouni Malinen 
Signed-off-by: Johannes Berg 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
--

mac80211: flush delayed work when entering suspend

2017-03-15T01:57:14+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: Greg Kroah-Hartman

mac80211: Fix adding of mesh vendor IEs

2017-02-14T23:22:51+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: Greg Kroah-Hartman

mac80211: initialize fast-xmit 'info' later

2017-01-12T10:22:43+00:00

commit 35f432a03e41d3bf08c51ede917f94e2288fbe8c upstream.

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.

Reported-by: Ben Greear 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

cfg80211/mac80211: fix BSS leaks when abandoning assoc attempts

2017-01-09T07:07:42+00:00

commit e6f462df9acd2a3295e5d34eb29e2823220cf129 upstream.

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.

Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: discard multicast and 4-addr A-MSDUs

2016-11-10T15:36:35+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: Greg Kroah-Hartman

mac80211: fix purging multicast PS buffer queue

2016-09-07T06:32:41+00:00

commit 6b07d9ca9b5363dda959b9582a3fc9c0b89ef3b5 upstream.

The code currently assumes that buffered multicast PS frames don't have
a pending ACK frame for tx status reporting.
However, hostapd sends a broadcast deauth frame on teardown for which tx
status is requested. This can lead to the "Have pending ack frames"
warning on module reload.
Fix this by using ieee80211_free_txskb/ieee80211_purge_tx_queue.

Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman