| Message ID | 20210511180259.159598-1-johannes@sipsolutions.net |
|---|---|
| Headers | show |
| Series | mac80211/driver security fixes | expand |
> +static bool ath10k_htt_rx_h_frag_pn_check(struct ath10k *ar, > + struct sk_buff *skb, > + u16 peer_id, > + u16 offset, > + enum htt_rx_mpdu_encrypt_type enctype) > +{ > + struct ath10k_peer *peer; > + union htt_rx_pn_t *last_pn, new_pn = {0}; > + struct ieee80211_hdr *hdr; > + bool more_frags; The variable more_frags is not getting used. > + new_pn.pn48 = ath10k_htt_rx_h_get_pn(ar, skb, offset, enctype); > + more_frags = ieee80211_has_morefrags(hdr->frame_control); "more_frags is assigned here but not used anywhere. I have raised a patch for remove this, I have raised a patch for this, https://patchwork.kernel.org/project/linux-wireless/patch/20210514220644.1.Iad576de95836b74aba80a5fc28d7131940eca190@changeid/ -Abhishek
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 > > > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com
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