From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-05-11 18:03:19
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.
johannes
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-05-11 18:03:17
From: Mathy Vanhoef <redacted>
Do not mix plaintext and encrypted fragments in protected Wi-Fi
networks. This fixes CVE-2020-26147.
Previously, an attacker was able to first forward a legitimate encrypted
fragment towards a victim, followed by a plaintext fragment. The
encrypted and plaintext fragment would then be reassembled. For further
details see Section 6.3 and Appendix D in the paper "Fragment and Forge:
Breaking Wi-Fi Through Frame Aggregation and Fragmentation".
Because of this change there are now two equivalent conditions in the
code to determine if a received fragment requires sequential PNs, so we
also move this test to a separate function to make the code easier to
maintain.
Cc: stable@vger.kernel.org
Signed-off-by: Mathy Vanhoef <redacted>
Signed-off-by: Johannes Berg <redacted>
---
net/mac80211/rx.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
@@ -2238,12 +2248,7 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)/* This is the first fragment of a new frame. */entry=ieee80211_reassemble_add(rx->sdata,frag,seq,rx->seqno_idx,&(rx->skb));-if(rx->key&&-(rx->key->conf.cipher==WLAN_CIPHER_SUITE_CCMP||-rx->key->conf.cipher==WLAN_CIPHER_SUITE_CCMP_256||-rx->key->conf.cipher==WLAN_CIPHER_SUITE_GCMP||-rx->key->conf.cipher==WLAN_CIPHER_SUITE_GCMP_256)&&-ieee80211_has_protected(fc)){+if(requires_sequential_pn(rx,fc)){intqueue=rx->security_idx;/* Store CCMP/GCMP PN so that we can verify that the
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-05-11 18:03:17
From: Mathy Vanhoef <redacted>
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 <redacted>
Signed-off-by: Johannes Berg <redacted>
---
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/key.c | 7 +++++++
net/mac80211/key.h | 2 ++
net/mac80211/rx.c | 6 ++++++
4 files changed, 16 insertions(+)
@@ -97,6 +97,7 @@ struct ieee80211_fragment_entry {u8rx_queue;boolcheck_sequential_pn;/* needed for CCMP/GCMP */u8last_pn[6];/* PN of the last fragment if CCMP was used */+unsignedintkey_color;};
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-05-11 18:03:18
From: Mathy Vanhoef <redacted>
Mitigate A-MSDU injection attacks (CVE-2020-24588) by detecting if the
destination address of a subframe equals an RFC1042 (i.e., LLC/SNAP)
header, and if so dropping the complete A-MSDU frame. This mitigates
known attacks, although new (unknown) aggregation-based attacks may
remain possible.
This defense works because in A-MSDU aggregation injection attacks, a
normal encrypted Wi-Fi frame is turned into an A-MSDU frame. This means
the first 6 bytes of the first A-MSDU subframe correspond to an RFC1042
header. In other words, the destination MAC address of the first A-MSDU
subframe contains the start of an RFC1042 header during an aggregation
attack. We can detect this and thereby prevent this specific attack.
For details, see Section 7.2 of "Fragment and Forge: Breaking Wi-Fi
Through Frame Aggregation and Fragmentation".
Note that for kernel 4.9 and above this patch depends on "mac80211:
properly handle A-MSDUs that start with a rfc1042 header". Otherwise
this patch has no impact and attacks will remain possible.
Cc: stable@vger.kernel.org
Signed-off-by: Mathy Vanhoef <redacted>
Signed-off-by: Johannes Berg <redacted>
---
net/wireless/util.c | 3 +++
1 file changed, 3 insertions(+)
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-05-11 18:03:18
From: Mathy Vanhoef <redacted>
Properly parse A-MSDUs whose first 6 bytes happen to equal a rfc1042
header. This can occur in practice when the destination MAC address
equals AA:AA:03:00:00:00. More importantly, this simplifies the next
patch to mitigate A-MSDU injection attacks.
Cc: stable@vger.kernel.org
Signed-off-by: Mathy Vanhoef <redacted>
Signed-off-by: Johannes Berg <redacted>
---
include/net/cfg80211.h | 4 ++--
net/mac80211/rx.c | 2 +-
net/wireless/util.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-05-11 18:03:18
From: Johannes Berg <redacted>
With old ciphers (WEP and TKIP) we shouldn't be using A-MSDUs
since A-MSDUs are only supported if we know that they are, and
the only practical way for that is HT support which doesn't
support old ciphers.
However, we would normally accept them anyway. Since we check
the MMIC before deaggregating A-MSDUs, and the A-MSDU bit in
the QoS header is not protected in TKIP (or WEP), this enables
attacks similar to CVE-2020-24588. To prevent that, drop A-MSDUs
completely with old ciphers.
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <redacted>
---
net/mac80211/rx.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-05-11 18:03:19
From: Johannes Berg <redacted>
EAPOL frames are used for authentication and key management between the
AP and each individual STA associated in the BSS. Those frames are not
supposed to be sent by one associated STA to another associated STA
(either unicast for broadcast/multicast).
Similarly, in 802.11 they're supposed to be sent to the authenticator
(AP) address.
Since it is possible for unexpected EAPOL frames to result in misbehavior
in supplicant implementations, it is better for the AP to not allow such
cases to be forwarded to other clients either directly, or indirectly if
the AP interface is part of a bridge.
Accept EAPOL (control port) frames only if they're transmitted to the
own address, or, due to interoperability concerns, to the PAE group
address.
Disable forwarding of EAPOL (or well, the configured control port
protocol) frames back to wireless medium in all cases. Previously, these
frames were accepted from fully authenticated and authorized stations
and also from unauthenticated stations for one of the cases.
Additionally, to avoid forwarding by the bridge, rewrite the PAE group
address case to the local MAC address.
Cc: stable@vger.kernel.org
Co-developed-by: Jouni Malinen <redacted>
Signed-off-by: Jouni Malinen <redacted>
Signed-off-by: Johannes Berg <redacted>
---
net/mac80211/rx.c | 33 +++++++++++++++++++++++++++------
1 file changed, 27 insertions(+), 6 deletions(-)
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-05-11 18:03:19
From: Johannes Berg <redacted>
As pointed out by Mathy Vanhoef, we implement the RX PN check
on fragmented frames incorrectly - we check against the last
received PN prior to the new frame, rather than to the one in
this frame itself.
Prior patches addressed the security issue here, but in order
to be able to reason better about the code, fix it to really
compare against the current frame's PN, not the last stored
one.
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <redacted>
---
net/mac80211/ieee80211_i.h | 11 +++++++++--
net/mac80211/rx.c | 5 ++---
net/mac80211/wpa.c | 13 +++++++++----
3 files changed, 20 insertions(+), 9 deletions(-)
@@ -167,8 +168,8 @@ ieee80211_rx_h_michael_mic_verify(struct ieee80211_rx_data *rx)update_iv:/* update IV in key information to be able to detect replays */-rx->key->u.tkip.rx[rx->security_idx].iv32=rx->tkip_iv32;-rx->key->u.tkip.rx[rx->security_idx].iv16=rx->tkip_iv16;+rx->key->u.tkip.rx[rx->security_idx].iv32=rx->tkip.iv32;+rx->key->u.tkip.rx[rx->security_idx].iv16=rx->tkip.iv16;returnRX_CONTINUE;
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-05-11 18:03:20
From: Johannes Berg <redacted>
Similar to the issues fixed in previous patches, TKIP and WEP
should be protected even if for TKIP we have the Michael MIC
protecting it, and WEP is broken anyway.
However, this also somewhat protects potential other algorithms
that drivers might implement.
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <redacted>
---
net/mac80211/rx.c | 12 ++++++++++++
net/mac80211/sta_info.h | 3 ++-
2 files changed, 14 insertions(+), 1 deletion(-)
@@ -2327,6 +2331,14 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)if(memcmp(pn,rpn,IEEE80211_CCMP_PN_LEN))returnRX_DROP_UNUSABLE;memcpy(entry->last_pn,pn,IEEE80211_CCMP_PN_LEN);+}elseif(entry->is_protected&&+(!rx->key||!ieee80211_has_protected(fc)||+rx->key->color!=entry->key_color)){+/* Drop this as a mixed key or fragment cache attack, even+*ifforTKIPMichaelMICshouldprotectus,andWEPisa+*lostcauseanyway.+*/+returnRX_DROP_UNUSABLE;}skb_pull(rx->skb,ieee80211_hdrlen(fc));
@@ -455,7 +455,8 @@ struct ieee80211_fragment_entry {u16extra_len;u16last_frag;u8rx_queue;-boolcheck_sequential_pn;/* needed for CCMP/GCMP */+u8check_sequential_pn:1,/* needed for CCMP/GCMP */+is_protected:1;u8last_pn[6];/* PN of the last fragment if CCMP was used */unsignedintkey_color;};
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-05-11 18:03:20
From: Wen Gong <redacted>
For some chips/drivers, e.g., QCA6174 with ath10k, the decryption is
done by the hardware, and the Protected bit in the Frame Control field
is cleared in the lower level driver before the frame is passed to
mac80211. In such cases, the condition for ieee80211_has_protected() is
not met in ieee80211_rx_h_defragment() of mac80211 and the new security
validation steps are not executed.
Extend mac80211 to cover the case where the Protected bit has been
cleared, but the frame is indicated as having been decrypted by the
hardware. This extends protection against mixed key and fragment cache
attack for additional drivers/chips. This fixes CVE-2020-24586 and
CVE-2020-24587 for such cases.
Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00110-QCARMSWP-1
Cc: stable@vger.kernel.org
Signed-off-by: Wen Gong <redacted>
Signed-off-by: Jouni Malinen <redacted>
Signed-off-by: Johannes Berg <redacted>
---
net/mac80211/rx.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
@@ -2332,13 +2335,19 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)returnRX_DROP_UNUSABLE;memcpy(entry->last_pn,pn,IEEE80211_CCMP_PN_LEN);}elseif(entry->is_protected&&-(!rx->key||!ieee80211_has_protected(fc)||+(!rx->key||+(!ieee80211_has_protected(fc)&&+!(status->flag&RX_FLAG_DECRYPTED))||rx->key->color!=entry->key_color)){/* Drop this as a mixed key or fragment cache attack, even*ifforTKIPMichaelMICshouldprotectus,andWEPisa*lostcauseanyway.*/returnRX_DROP_UNUSABLE;+}elseif(entry->is_protected&&rx->key&&+entry->key_color!=rx->key->color&&+(status->flag&RX_FLAG_DECRYPTED)){+returnRX_DROP_UNUSABLE;}skb_pull(rx->skb,ieee80211_hdrlen(fc));
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-05-11 18:03:20
From: Johannes Berg <redacted>
Prior patches protected against fragmentation cache attacks
by coloring keys, but this shows that it can lead to issues
when multiple stations use the same sequence number. Add a
fragment cache to struct sta_info (in addition to the one in
the interface) to separate fragments for different stations
properly.
This then automatically clear most of the fragment cache when a
station disconnects (or reassociates) from an AP, or when client
interfaces disconnect from the network, etc.
On the way, also fix the comment there since this brings us in line
with the recommendation in 802.11-2016 ("An AP should support ...").
Additionally, remove a useless condition (since there's no problem
purging an already empty list).
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <redacted>
---
net/mac80211/ieee80211_i.h | 26 ++++--------------------
net/mac80211/iface.c | 11 +++-------
net/mac80211/rx.c | 41 ++++++++++++++++++++++++++++----------
net/mac80211/sta_info.c | 6 +++++-
net/mac80211/sta_info.h | 32 ++++++++++++++++++++++++++++-
5 files changed, 73 insertions(+), 43 deletions(-)
@@ -50,12 +50,6 @@ struct ieee80211_local;#define IEEE80211_ENCRYPT_HEADROOM 8#define IEEE80211_ENCRYPT_TAILROOM 18-/* IEEE 802.11 (Ch. 9.5 Defragmentation) requires support for concurrent-*receptionofatleastthreefragmentedframes.Thislimitcanbeincreased-*bychangingthisdefine,atthecostofslowerframereassemblyand-*increasedmemoryuse(about2kBofRAMperentry).*/-#define IEEE80211_FRAGMENT_MAX 4-/* power level hasn't been configured (or set to automatic) */#define IEEE80211_UNSET_POWER_LEVEL INT_MIN
@@ -88,19 +82,6 @@ extern const u8 ieee80211_ac_to_qos_mask[IEEE80211_NUM_ACS];#define IEEE80211_MAX_NAN_INSTANCE_ID 255-structieee80211_fragment_entry{-structsk_buff_headskb_list;-unsignedlongfirst_frag_time;-u16seq;-u16extra_len;-u16last_frag;-u8rx_queue;-boolcheck_sequential_pn;/* needed for CCMP/GCMP */-u8last_pn[6];/* PN of the last fragment if CCMP was used */-unsignedintkey_color;-};--structieee80211_bss{u32device_ts_beacon,device_ts_presp;
@@ -903,9 +884,7 @@ struct ieee80211_sub_if_data {charname[IFNAMSIZ];-/* Fragment table for host-based reassembly */-structieee80211_fragment_entryfragments[IEEE80211_FRAGMENT_MAX];-unsignedintfragment_next;+structieee80211_fragment_cachefrags;/* TID bitmap for NoAck policy */u16noack_map;
@@ -2123,19 +2123,34 @@ ieee80211_rx_h_decrypt(struct ieee80211_rx_data *rx)returnresult;}+voidieee80211_init_frag_cache(structieee80211_fragment_cache*cache)+{+inti;++for(i=0;i<ARRAY_SIZE(cache->entries);i++)+skb_queue_head_init(&cache->entries[i].skb_list);+}++voidieee80211_destroy_frag_cache(structieee80211_fragment_cache*cache)+{+inti;++for(i=0;i<ARRAY_SIZE(cache->entries);i++)+__skb_queue_purge(&cache->entries[i].skb_list);+}+staticinlinestructieee80211_fragment_entry*-ieee80211_reassemble_add(structieee80211_sub_if_data*sdata,+ieee80211_reassemble_add(structieee80211_fragment_cache*cache,unsignedintfrag,unsignedintseq,intrx_queue,structsk_buff**skb){structieee80211_fragment_entry*entry;-entry=&sdata->fragments[sdata->fragment_next++];-if(sdata->fragment_next>=IEEE80211_FRAGMENT_MAX)-sdata->fragment_next=0;+entry=&cache->entries[cache->next++];+if(cache->next>=IEEE80211_FRAGMENT_MAX)+cache->next=0;-if(!skb_queue_empty(&entry->skb_list))-__skb_queue_purge(&entry->skb_list);+__skb_queue_purge(&entry->skb_list);__skb_queue_tail(&entry->skb_list,*skb);/* no need for locking */*skb=NULL;
@@ -2246,7 +2265,7 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)if(frag==0){/* This is the first fragment of a new frame. */-entry=ieee80211_reassemble_add(rx->sdata,frag,seq,+entry=ieee80211_reassemble_add(cache,frag,seq,rx->seqno_idx,&(rx->skb));if(requires_sequential_pn(rx,fc)){intqueue=rx->security_idx;
@@ -2274,7 +2293,7 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)/* This is a fragment for a frame that should already be pending in*fragmentcache.Addthisfragmenttotheendofthependingentry.*/-entry=ieee80211_reassemble_find(rx->sdata,frag,seq,+entry=ieee80211_reassemble_find(cache,frag,seq,rx->seqno_idx,hdr);if(!entry){I802_DEBUG_INC(rx->local->rx_handlers_drop_defrag);
@@ -392,6 +392,8 @@ struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata,u64_stats_init(&sta->rx_stats.syncp);+ieee80211_init_frag_cache(&sta->frags);+sta->sta_state=IEEE80211_STA_NONE;/* Mark TID as unreserved */
@@ -438,6 +438,33 @@ struct ieee80211_sta_rx_stats {u64msdu[IEEE80211_NUM_TIDS+1];};+/*+*IEEE802.11-2016(10.6"Defragmentation")recommendssupportfor"concurrent+*receptionofatleastoneMSDUperaccesscategoryperassociatedSTA"+*onAPs,or"at least one MSDU per access category"onotherinterfacetypes.+*+*Thislimitcanbeincreasedbychangingthisdefine,atthecostofslower+*framereassemblyandincreasedmemoryusewhilefragmentsarepending.+*/+#define IEEE80211_FRAGMENT_MAX 4++structieee80211_fragment_entry{+structsk_buff_headskb_list;+unsignedlongfirst_frag_time;+u16seq;+u16extra_len;+u16last_frag;+u8rx_queue;+boolcheck_sequential_pn;/* needed for CCMP/GCMP */+u8last_pn[6];/* PN of the last fragment if CCMP was used */+unsignedintkey_color;+};++structieee80211_fragment_cache{+structieee80211_fragment_entryentries[IEEE80211_FRAGMENT_MAX];+unsignedintnext;+};+/**Thebandwidththresholdbelowwhichtheper-stationCoDelparameterswillbe*scaledtobemorelenient(topreventstarvationofslowstations).This
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-05-11 18:03:21
From: Wen Gong <redacted>
PN replay check for not fragmented frames is finished in the firmware,
but this was not done for fragmented frames when ath10k is used with
QCA6174/QCA6377 PCIe. mac80211 has the function
ieee80211_rx_h_defragment() for PN replay check for fragmented frames,
but this does not get checked with QCA6174 due to the
ieee80211_has_protected() condition not matching the cleared Protected
bit case.
Validate the PN of received fragmented frames within ath10k when CCMP is
used and drop the fragment if the PN is not correct (incremented by
exactly one from the previous fragment). This applies only for
QCA6174/QCA6377 PCIe.
Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00110-QCARMSWP-1
Cc: stable@vger.kernel.org
Signed-off-by: Wen Gong <redacted>
Signed-off-by: Jouni Malinen <redacted>
Signed-off-by: Johannes Berg <redacted>
---
drivers/net/wireless/ath/ath10k/htt.h | 1 +
drivers/net/wireless/ath/ath10k/htt_rx.c | 99 +++++++++++++++++++++++-
2 files changed, 96 insertions(+), 4 deletions(-)
@@ -1946,13 +1956,20 @@ static void ath10k_htt_rx_h_mpdu(struct ath10k *ar,0,enctype);-if(!frag_pn_check){-/* Discard the fragment with invalid PN */+if(frag)+multicast_check=ath10k_htt_rx_h_frag_multicast_check(ar,+msdu,+0);++if(!frag_pn_check||!multicast_check){+/* Discard the fragment with invalid PN or multicast DA+*/temp=msdu->prev;__skb_unlink(msdu,amsdu);dev_kfree_skb_any(msdu);msdu=temp;frag_pn_check=true;+multicast_check=true;continue;}
@@ -2617,6 +2617,13 @@ static bool ath10k_htt_rx_proc_rx_frag_ind_hl(struct ath10k_htt *htt,rx_desc=(structhtt_hl_rx_desc*)(skb->data+tot_hdr_len);rx_desc_info=__le32_to_cpu(rx_desc->info);+hdr=(structieee80211_hdr*)((u8*)rx_desc+rx_hl->fw_desc.len);++if(is_multicast_ether_addr(hdr->addr1)){+/* Discard the fragment with multicast DA */+gotoerr;+}+if(!MS(rx_desc_info,HTT_RX_DESC_HL_INFO_ENCRYPTED)){spin_unlock_bh(&ar->data_lock);returnath10k_htt_rx_proc_rx_ind_hl(htt,&resp->rx_ind_hl,skb,
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-05-11 18:03:23
From: Wen Gong <redacted>
When the discard flag is set by the firmware for an MPDU, it should be
dropped. This allows a mitigation for CVE-2020-24588 to be implemented
in the firmware.
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049
Cc: stable@vger.kernel.org
Signed-off-by: Wen Gong <redacted>
Signed-off-by: Jouni Malinen <redacted>
Signed-off-by: Johannes Berg <redacted>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 5 +++++
drivers/net/wireless/ath/ath10k/rx_desc.h | 14 +++++++++++++-
2 files changed, 18 insertions(+), 1 deletion(-)
@@ -2312,6 +2312,11 @@ static bool ath10k_htt_rx_proc_rx_ind_hl(struct ath10k_htt *htt,fw_desc=&rx->fw_desc;rx_desc_len=fw_desc->len;+if(fw_desc->u.bits.discard){+ath10k_dbg(ar,ATH10K_DBG_HTT,"htt discard mpdu\n");+gotoerr;+}+/* I have not yet seen any case where num_mpdu_ranges > 1.*qcaclddoesnotseemhandlethatcaseeither,soweintroducethe*samelimitiationhereaswell.
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-05-11 18:03:24
From: Sriram R <redacted>
In certain scenarios a normal MSDU can be received as an A-MSDU when
the A-MSDU present bit of a QoS header gets flipped during reception.
Since this bit is unauthenticated, the hardware crypto engine can pass
the frame to the driver without any error indication.
This could result in processing unintended subframes collected in the
A-MSDU list. Hence, validate A-MSDU list by checking if the first frame
has a valid subframe header.
Comparing the non-aggregated MSDU and an A-MSDU, the fields of the first
subframe DA matches the LLC/SNAP header fields of a normal MSDU.
In order to avoid processing such frames, add a validation to
filter such A-MSDU frames where the first subframe header DA matches
with the LLC/SNAP header pattern.
Tested-on: QCA9984 hw1.0 PCI 10.4-3.10-00047
Cc: stable@vger.kernel.org
Signed-off-by: Sriram R <redacted>
Signed-off-by: Jouni Malinen <redacted>
Signed-off-by: Johannes Berg <redacted>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 61 ++++++++++++++++++++++--
1 file changed, 57 insertions(+), 4 deletions(-)
@@ -2108,14 +2108,62 @@ static void ath10k_htt_rx_h_unchain(struct ath10k *ar,ath10k_unchain_msdu(amsdu,unchain_cnt);}+staticboolath10k_htt_rx_validate_amsdu(structath10k*ar,+structsk_buff_head*amsdu)+{+u8*subframe_hdr;+structsk_buff*first;+boolis_first,is_last;+structhtt_rx_desc*rxd;+structieee80211_hdr*hdr;+size_thdr_len,crypto_len;+enumhtt_rx_mpdu_encrypt_typeenctype;+intbytes_aligned=ar->hw_params.decap_align_bytes;++first=skb_peek(amsdu);++rxd=(void*)first->data-sizeof(*rxd);+hdr=(void*)rxd->rx_hdr_status;++is_first=!!(rxd->msdu_end.common.info0&+__cpu_to_le32(RX_MSDU_END_INFO0_FIRST_MSDU));+is_last=!!(rxd->msdu_end.common.info0&+__cpu_to_le32(RX_MSDU_END_INFO0_LAST_MSDU));++/* Return in case of non-aggregated msdu */+if(is_first&&is_last)+returntrue;++/* First msdu flag is not set for the first msdu of the list */+if(!is_first)+returnfalse;++enctype=MS(__le32_to_cpu(rxd->mpdu_start.info0),+RX_MPDU_START_INFO0_ENCRYPT_TYPE);++hdr_len=ieee80211_hdrlen(hdr->frame_control);+crypto_len=ath10k_htt_rx_crypto_param_len(ar,enctype);++subframe_hdr=(u8*)hdr+round_up(hdr_len,bytes_aligned)++crypto_len;++/* Validate if the amsdu has a proper first subframe.+*Therearechancesasinglemsducanbereceivedasamsduwhen+*theunauthenticatedamsduflagofaQoSheader+*getsflippedinnon-SPPAMSDU's,insuchcasesthefirst+*subframehasllc/snapheaderinplaceofavalidda.+*returnfalseifthedamatchesrfc1042pattern+*/+if(ether_addr_equal(subframe_hdr,rfc1042_header))+returnfalse;++returntrue;+}+staticboolath10k_htt_rx_amsdu_allowed(structath10k*ar,structsk_buff_head*amsdu,structieee80211_rx_status*rx_status){-/* FIXME: It might be a good idea to do some fuzzy-testing to drop-*invalid/dangerousframes.-*/-if(!rx_status->freq){ath10k_dbg(ar,ATH10K_DBG_HTT,"no channel configured; ignoring frame(s)!\n");returnfalse;
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-05-11 18:03:24
From: Wen Gong <redacted>
TKIP Michael MIC was not verified properly for PCIe cases since the
validation steps in ieee80211_rx_h_michael_mic_verify() in mac80211 did
not get fully executed due to unexpected flag values in
ieee80211_rx_status.
Fix this by setting the flags property to meet mac80211 expectations for
performing Michael MIC validation there. This fixes CVE-2020-26141. It
does the same as ath10k_htt_rx_proc_rx_ind_hl() for SDIO which passed
MIC verification case. This applies only to QCA6174/QCA9377 PCIe.
Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00110-QCARMSWP-1
Cc: stable@vger.kernel.org
Signed-off-by: Wen Gong <redacted>
Signed-off-by: Jouni Malinen <redacted>
Signed-off-by: Johannes Berg <redacted>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 10 ++++++++++
1 file changed, 10 insertions(+)
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-05-11 18:03:25
From: Sriram R <redacted>
Currently the fragment cache setup during peer assoc is
cleared only during peer delete. In case a key reinstallation
happens with the same peer, the same fragment cache with old
fragments added before key installation could be clubbed
with fragments received after. This might be exploited
to mix fragments of different data resulting in a proper
unintended reassembled packet to be passed up the stack.
Hence flush the fragment cache on every key installation to prevent
potential attacks (CVE-2020-24587).
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01734-QCAHKSWPL_SILICONZ-1 v2
Cc: stable@vger.kernel.org
Signed-off-by: Sriram R <redacted>
Signed-off-by: Jouni Malinen <redacted>
Signed-off-by: Johannes Berg <redacted>
---
drivers/net/wireless/ath/ath11k/dp_rx.c | 18 ++++++++++++++++++
drivers/net/wireless/ath/ath11k/dp_rx.h | 1 +
drivers/net/wireless/ath/ath11k/mac.c | 6 ++++++
3 files changed, 25 insertions(+)
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-05-11 18:03:28
From: Sriram R <redacted>
Fragmentation is used only with unicast frames. Drop multicast fragments
to avoid any undesired behavior.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01734-QCAHKSWPL_SILICONZ-1 v2
Cc: stable@vger.kernel.org
Signed-off-by: Sriram R <redacted>
Signed-off-by: Jouni Malinen <redacted>
Signed-off-by: Johannes Berg <redacted>
---
drivers/net/wireless/ath/ath11k/dp_rx.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
@@ -3468,6 +3478,7 @@ static int ath11k_dp_rx_frag_h_mpdu(struct ath11k *ar,u8tid;intret=0;boolmore_frags;+boolis_mcbc;rx_desc=(structhal_rx_desc*)msdu->data;peer_id=ath11k_dp_rx_h_mpdu_start_peer_id(ar->ab,rx_desc);
@@ -3475,6 +3486,11 @@ static int ath11k_dp_rx_frag_h_mpdu(struct ath11k *ar,seqno=ath11k_dp_rx_h_mpdu_start_seq_no(ar->ab,rx_desc);frag_no=ath11k_dp_rx_h_mpdu_start_frag_no(ar->ab,msdu);more_frags=ath11k_dp_rx_h_mpdu_start_more_frags(ar->ab,msdu);+is_mcbc=ath11k_dp_rx_h_attn_is_mcbc(ar->ab,rx_desc);++/* Multicast/Broadcast fragments are not expected */+if(is_mcbc)+return-EINVAL;if(!ath11k_dp_rx_h_mpdu_start_seq_ctrl_valid(ar->ab,rx_desc)||!ath11k_dp_rx_h_mpdu_start_fc_valid(ar->ab,rx_desc)||
@@ -2312,6 +2312,11 @@ static bool ath10k_htt_rx_proc_rx_ind_hl(struct ath10k_htt *htt,fw_desc=&rx->fw_desc;rx_desc_len=fw_desc->len;+if(fw_desc->u.bits.discard){+ath10k_dbg(ar,ATH10K_DBG_HTT,"htt discard mpdu\n");+gotoerr;+}+/* I have not yet seen any case where num_mpdu_ranges > 1.*qcaclddoesnotseemhandlethatcaseeither,soweintroducethe*samelimitiationhereaswell.
Am I misled here, or are you introducing endianness issues here? From C99:
"The order of allocation of bit-fields within a unit (high-order to
low-order or low-order to high-order) is implementation-defined."
Now, we're pretty well attuned to two implementations (big and little
endian), and this should work for the most common one (little endian),
but it's not wise to assume everyone is little endian.
Brian
ath10k_htt *htt,
fw_desc = &rx->fw_desc;
rx_desc_len = fw_desc->len;
+ if (fw_desc->u.bits.discard) {
+ ath10k_dbg(ar, ATH10K_DBG_HTT, "htt discard mpdu\n");
+ goto err;
+ }
+
/* I have not yet seen any case where num_mpdu_ranges > 1.
* qcacld does not seem handle that case either, so we
introduce
the
* same limitiation here as well.
Am I misled here, or are you introducing endianness issues here? From
C99:
"The order of allocation of bit-fields within a unit (high-order to
low-order or low-order to high-order) is implementation-defined."
Now, we're pretty well attuned to two implementations (big and little
endian), and this should work for the most common one (little endian),
but it's not wise to assume everyone is little endian.
Brian
This issue was identified in internal review, but due to the embargo
expiring
we sent it out as-is since that is what had been tested. The author will
have
a follow-up change to replace this.
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project
From: Ben Greear <hidden> Date: 2021-05-17 18:54:48
On 5/11/21 11:02 AM, Johannes Berg wrote:
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
Is anyone backporting this to 4.19 and other 'stable' kernels?
For anyone using ath10k-ct driver, I have initial update of the
driver done for 4.19 (owrt uses this), but cannot compile against
the 4.19 kernel unless the mac80211 changes are also backported.
In interest of not duplicating effort...I was hoping these would
just show up in the 4.19 stable sometime soon...
Thanks,
Ben
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.
johannes