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

Kalle Valo kvalo at
Mon Sep 7 11:46:18 EDT 2020

Baptiste Jonglez <baptiste at> writes:

> Hi,
> Cross-posting to openwrt-devel because we are backporting the necessary fixes.
> On 12-08-20, Jouni Malinen wrote:
>> On Wed, Aug 12, 2020 at 11:17:47AM +0200, Toke H?iland-J?rgensen wrote:
>> > Pali Roh?r <pali at> writes:
>> > > 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")
>> Those cover most of the identified issues for drivers using mac80211
>> (e.g., ath9k and ath10k; though, I don't remember whether I actually
>> ever managed to reproduce this with ath10k in practice). I have couple
>> of additional ath9k-specific patches that cover additional lower layer
>> paths for this. I hope to get those out after confirming they work with
>> the current kernel tree snapshot.
> I could find linux-stable backports for ce2e1ca70307 and b16798f5b907, but
> not for a0761a301746.  Is it intended?  From the commit message, it looks
> like it does fix an important issue.
> Also, for the sake of completeness, this subsequent commit is also related
> to CVE-2020-3702 (and already backported):
> 5981fe5b0529 ("mac80211: fix misplaced while instead of if")

I think you should ask the stable to also take commit a0761a301746, most
likely they just missed it by accident.


More information about the ath10k mailing list