CVE-2020-3702: Firmware updates for ath9k and ath10k chips

Pali Rohár pali at kernel.org
Wed Aug 12 05:31:09 EDT 2020


On Wednesday 12 August 2020 11:17:47 Toke Høiland-Jørgensen wrote:
> Pali Rohár <pali at kernel.org> writes:
> 
> > On Monday 10 August 2020 11:01:26 Pali Rohár wrote:
> >> Hello!
> >> 
> >> ESET engineers on their blog published some information about new
> >> security vulnerability CVE-2020-3702 in ath9k wifi cards:
> >> https://www.welivesecurity.com/2020/08/06/beyond-kr00k-even-more-wifi-chips-vulnerable-eavesdropping/
> >> 
> >> According to Qualcomm security bulletin this CVE-2020-3702 affects also
> >> some Qualcomm IPQ chips which are handled by ath10k driver:
> >> https://www.qualcomm.com/company/product-security/bulletins/august-2020-security-bulletin#_cve-2020-3702
> >> 
> >> Kalle, could you or other people from Qualcomm provide updated and fixed
> >> version of ath9k and ath10k firmwares in linux-firmware git repository?
> >> 
> >> According to Qualcomm security bulletin this issue has Critical security
> >> rating, so I think fixed firmware files should be updated also in stable
> >> releases of linux distributions.
> >
> > Hello!
> >
> > Qualcomm has already sent following statement to media:
> >
> >     Qualcomm has already made mitigations available to OEMs in May 2020,
> >     and we encourage end users to update their devices as patches have
> >     become available from OEMs.
> >
> > And based on information from ESET blog post, Qualcomm's proprietary
> > driver for these wifi cards is fixed since Qualcomm July release.
> >
> > Could somebody react and provide some details when fixes would be
> > available for ath9k and ath10k Linux drivers? And what is current state
> > of this issue for Linux?
> >
> > I'm looking at ath9k and ath10k git trees [1] [2] [3] and I do not see
> > there any change which could be related to CVE-2020-3702.
> 
> How about these, from March:
> 
> a0761a301746 ("mac80211: drop data frames without key on encrypted links")
> ce2e1ca70307 ("mac80211: Check port authorization in the ieee80211_tx_dequeue() case")
> b16798f5b907 ("mac80211: mark station unauthorized before key removal")

Thank you for update! I will look at these commits if they are relevant.
Because ESET wrote that problem is in ath9k driver I have not looked at
mac80211 layer code.

> -Toke
> 



More information about the ath10k mailing list