mac80211: backport upstream fixes for FragAttacks

From the patch series description:

Several security issues in the 802.11 implementations were found by
Mathy Vanhoef (New York University Abu Dhabi), who has published all
the details at

	https://papers.mathyvanhoef.com/usenix2021.pdf

Specifically, the following CVEs were assigned:

 * CVE-2020-24586 - Fragmentation cache not cleared on reconnection
 * CVE-2020-24587 - Reassembling fragments encrypted under different
                    keys
 * CVE-2020-24588 - Accepting non-SPP A-MSDU frames, which leads to
                    payload being parsed as an L2 frame under an
                    A-MSDU bit toggling attack
 * CVE-2020-26139 - Forwarding EAPOL from unauthenticated sender
 * CVE-2020-26140 - Accepting plaintext data frames in protected
                    networks
 * CVE-2020-26141 - Not verifying TKIP MIC of fragmented frames
 * CVE-2020-26142 - Processing fragmented frames as full frames
 * CVE-2020-26143 - Accepting fragmented plaintext frames in
                    protected networks
 * CVE-2020-26144 - Always accepting unencrypted A-MSDU frames that
                    start with RFC1042 header with EAPOL ethertype
 * CVE-2020-26145 - Accepting plaintext broadcast fragments as full
                    frames
 * CVE-2020-26146 - Reassembling encrypted fragments with non-consecutive
                    packet numbers
 * CVE-2020-26147 - Reassembling mixed encrypted/plaintext fragments

In general, the scope of these attacks is that they may allow an
attacker to
 * inject L2 frames that they can more or less control (depending on the
   vulnerability and attack method) into an otherwise protected network;
 * exfiltrate (some) network data under certain conditions, this is
   specific to the fragmentation issues.

A subset of these issues is known to apply to the Linux IEEE 802.11
implementation (mac80211). Where it is affected, the attached patches
fix the issues, even if not all of them reference the exact CVE IDs.

In addition, driver and/or firmware updates may be necessary, as well
as potentially more fixes to mac80211, depending on how drivers are
using it.

Specifically, for Intel devices, firmware needs to be updated to the
most recently released versions (which was done without any reference
to the security issues) to address some of the vulnerabilities.

To have a single set of patches, I'm also including patches for the
ath10k and ath11k drivers here.

We currently don't have information about how other drivers are, if
at all, affected.

Signed-off-by: Felix Fietkau <nbd@nbd.name>

1 files changed, 87 insertions, 0 deletions

diff --git a/package/kernel/mac80211/patches/subsys/381-mac80211-prevent-mixed-key-and-fragment-cache-attack.patch b/package/kernel/mac80211/patches/subsys/381-mac80211-prevent-mixed-key-and-fragment-cache-attack.patch
new file mode 100644
index 0000000000..de0f89a5b0
--- /dev/null
+++ b/package/kernel/mac80211/patches/subsys/381-mac80211-prevent-mixed-key-and-fragment-cache-attack.patch
@@ -0,0 +1,87 @@
+From: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
+Date: Tue, 11 May 2021 20:02:43 +0200
+Subject: [PATCH] mac80211: prevent mixed key and fragment cache attacks
+
+Simultaneously prevent mixed key attacks (CVE-2020-24587) and fragment
+cache attacks (CVE-2020-24586). This is accomplished by assigning a
+unique color to every key (per interface) and using this to track which
+key was used to decrypt a fragment. When reassembling frames, it is
+now checked whether all fragments were decrypted using the same key.
+
+To assure that fragment cache attacks are also prevented, the ID that is
+assigned to keys is unique even over (re)associations and (re)connects.
+This means fragments separated by a (re)association or (re)connect will
+not be reassembled. Because mac80211 now also prevents the reassembly of
+mixed encrypted and plaintext fragments, all cache attacks are prevented.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+---
+
+--- a/net/mac80211/ieee80211_i.h
++++ b/net/mac80211/ieee80211_i.h
+@@ -97,6 +97,7 @@ struct ieee80211_fragment_entry {
+ 	u8 rx_queue;
+ 	bool check_sequential_pn; /* needed for CCMP/GCMP */
+ 	u8 last_pn[6]; /* PN of the last fragment if CCMP was used */
++	unsigned int key_color;
+ };
+ 
+ 
+--- a/net/mac80211/key.c
++++ b/net/mac80211/key.c
+@@ -799,6 +799,7 @@ int ieee80211_key_link(struct ieee80211_
+ 		       struct ieee80211_sub_if_data *sdata,
+ 		       struct sta_info *sta)
+ {
++	static atomic_t key_color = ATOMIC_INIT(0);
+ 	struct ieee80211_key *old_key;
+ 	int idx = key->conf.keyidx;
+ 	bool pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
+@@ -850,6 +851,12 @@ int ieee80211_key_link(struct ieee80211_
+ 	key->sdata = sdata;
+ 	key->sta = sta;
+ 
++	/*
++	 * Assign a unique ID to every key so we can easily prevent mixed
++	 * key and fragment cache attacks.
++	 */
++	key->color = atomic_inc_return(&key_color);
++
+ 	increment_tailroom_need_count(sdata);
+ 
+ 	ret = ieee80211_key_replace(sdata, sta, pairwise, old_key, key);
+--- a/net/mac80211/key.h
++++ b/net/mac80211/key.h
+@@ -128,6 +128,8 @@ struct ieee80211_key {
+ 	} debugfs;
+ #endif
+ 
++	unsigned int color;
++
+ 	/*
+ 	 * key config, must be last because it contains key
+ 	 * material as variable length member
+--- a/net/mac80211/rx.c
++++ b/net/mac80211/rx.c
+@@ -2265,6 +2265,7 @@ ieee80211_rx_h_defragment(struct ieee802
+ 			 * next fragment has a sequential PN value.
+ 			 */
+ 			entry->check_sequential_pn = true;
++			entry->key_color = rx->key->color;
+ 			memcpy(entry->last_pn,
+ 			       rx->key->u.ccmp.rx_pn[queue],
+ 			       IEEE80211_CCMP_PN_LEN);
+@@ -2302,6 +2303,11 @@ ieee80211_rx_h_defragment(struct ieee802
+ 
+ 		if (!requires_sequential_pn(rx, fc))
+ 			return RX_DROP_UNUSABLE;
++
++		/* Prevent mixed key and fragment cache attacks */
++		if (entry->key_color != rx->key->color)
++			return RX_DROP_UNUSABLE;
++
+ 		memcpy(pn, entry->last_pn, IEEE80211_CCMP_PN_LEN);
+ 		for (i = IEEE80211_CCMP_PN_LEN - 1; i >= 0; i--) {
+ 			pn[i]++;