Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752837AbdGPOOC (ORCPT ); Sun, 16 Jul 2017 10:14:02 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:44258 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751884AbdGPOOA (ORCPT ); Sun, 16 Jul 2017 10:14:00 -0400 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Jouni Malinen" , "David S. Miller" , "Johannes Berg" Date: Sun, 16 Jul 2017 14:56:46 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 161/178] mac80211: reject ToDS broadcast data frames In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2473 Lines: 68 3.16.46-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Johannes Berg 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 -- 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 [bwh: Backported to 3.16: Put the new code in an else-block since the previous if-blocks may or may not return] Signed-off-by: Ben Hutchings --- net/mac80211/rx.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -3140,6 +3140,30 @@ static bool prepare_for_handlers(struct if (!ieee80211_is_beacon(hdr->frame_control)) return false; status->rx_flags &= ~IEEE80211_RX_RA_MATCH; + } else { + /* + * 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; } break; case NL80211_IFTYPE_WDS: