Patch "mac80211: reject ToDS broadcast data frames" has been added to the 4.9-stable tree

This is a note to let you know that I've just added the patch titled

mac80211: reject ToDS broadcast data frames

to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
mac80211-reject-tods-broadcast-data-frames.patch
and it can be found in the queue-4.9 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From: Johannes Berg <[email protected]>
Date: Thu, 20 Apr 2017 21:32:16 +0200
Subject: mac80211: reject ToDS broadcast data frames

From: Johannes Berg <[email protected]>

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.

--

---
 net/mac80211/rx.c |   21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

@@ -3617,6 +3617,27 @@ static bool ieee80211_accept_frame(struc
 			    !ether_addr_equal(bssid, hdr->addr1))
 				return false;
 		}
+
+		/*
+		 * 802.11-2016 Table 9-26 says that for data frames, A1 must be
+		 * the BSSID - we've checked that already but may have accepted
+		 * the wildcard (ff:ff:ff:ff:ff:ff).
+		 *
+		 * It also says:
+		 *	The BSSID of the Data frame is determined as follows:
+		 *	a) If the STA is contained within an AP or is associated
+		 *	   with an AP, the BSSID is the address currently in use
+		 *	   by the STA contained in the AP.
+		 *
+		 * So we should not accept data frames with an address that's
+		 * multicast.
+		 *
+		 * Accepting it also opens a security problem because stations
+		 * could encrypt it with the GTK and inject traffic that way.
+		 */
+		if (ieee80211_is_data(hdr->frame_control) && multicast)
+			return false;
+
 		return true;
 	case NL80211_IFTYPE_WDS:
 		if (bssid || !ieee80211_is_data(hdr->frame_control))

Patches currently in stable-queue which might be from [email protected] are

queue-4.9/mac80211-fix-mu-mimo-follow-mac-mode.patch queue-4.9/mac80211-reject-tods-broadcast-data-frames.patch