mac80211: reject ToDS broadcast data frames
authorJohannes Berg <johannes.berg@intel.com>
Thu, 20 Apr 2017 19:32:16 +0000 (21:32 +0200)
committerBen Hutchings <ben@decadent.org.uk>
Tue, 18 Jul 2017 17:38:43 +0000 (18:38 +0100)
commita6dc29a3f070d646cd7de801e30e4df0fca3cd96
treefe3fadcd381859d478403feca700429c7046b717
parent1dc90d7f54633c64bb56778723f1b331bd6507ef
mac80211: reject ToDS broadcast data frames

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 <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
--
Dave, I didn't want to send you a new pull request for a single
commit yet again - can you apply this one patch as is?
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.2: Put the new code in an else-block since the
 previous if-blocks may or may not return]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
net/mac80211/rx.c