stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: "Pali Rohár" <pali@kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, Kalle Valo <kvalo@codeaurora.org>,
	linux-wireless@vger.kernel.org
Subject: Re: Backporting CVE-2020-3702 ath9k patches to stable
Date: Fri, 20 Aug 2021 17:23:08 -0400	[thread overview]
Message-ID: <YSAdPJFhmTztd+0Z@sashalap> (raw)
In-Reply-To: <20210820113505.dgcsurognowp6xqp@pali>

On Fri, Aug 20, 2021 at 01:35:05PM +0200, Pali Rohár wrote:
>On Wednesday 18 August 2021 11:18:29 Greg KH wrote:
>> On Wed, Aug 18, 2021 at 11:10:27AM +0200, Pali Rohár wrote:
>> > On Wednesday 18 August 2021 11:02:47 Greg KH wrote:
>> > > On Wed, Aug 18, 2021 at 10:48:59AM +0200, Pali Rohár wrote:
>> > > > Hello! I would like to request for backporting following ath9k commits
>> > > > which are fixing CVE-2020-3702 issue.
>> > > >
>> > > > 56c5485c9e44 ("ath: Use safer key clearing with key cache entries")
>> > > > 73488cb2fa3b ("ath9k: Clear key cache explicitly on disabling hardware")
>> > > > d2d3e36498dd ("ath: Export ath_hw_keysetmac()")
>> > > > 144cd24dbc36 ("ath: Modify ath_key_delete() to not need full key entry")
>> > > > ca2848022c12 ("ath9k: Postpone key cache entry deletion for TXQ frames reference it")
>> > > >
>> > > > See also:
>> > > > https://lore.kernel.org/linux-wireless/87o8hvlx5g.fsf@codeaurora.org/
>> > > >
>> > > > This CVE-2020-3702 issue affects ath9k driver in stable kernel versions.
>> > > > And due to this issue Qualcomm suggests to not use open source ath9k
>> > > > driver and instead to use their proprietary driver which do not have
>> > > > this issue.
>> > > >
>> > > > Details about CVE-2020-3702 are described on the ESET blog post:
>> > > > https://www.welivesecurity.com/2020/08/06/beyond-kr00k-even-more-wifi-chips-vulnerable-eavesdropping/
>> > > >
>> > > > Two months ago ESET tested above mentioned commits applied on top of
>> > > > 4.14 stable tree and confirmed that issue cannot be reproduced anymore
>> > > > with those patches. Commits were applied cleanly on top of 4.14 stable
>> > > > tree without need to do any modification.
>> > >
>> > > What stable tree(s) do you want to see these go into?
>> >
>> > Commits were introduced in 5.12, so it should go to all stable trees << 5.12
>> >
>> > > And what order are the above commits to be applied in, top-to-bottom or
>> > > bottom-to-top?
>> >
>> > Same order in which were applied in 5.12. So first commit to apply is
>> > 56c5485c9e44, then 73488cb2fa3b and so on... (from top of the email to
>> > the bottom of email).
>>
>> Great, all now queued up.  Sad that qcom didn't want to do this
>> themselves :(
>>
>> greg k-h
>
>It is sad, but Qualcomm support said that they have fixed it in their
>proprietary driver in July 2020 (so more than year ago) and that open
>source drivers like ath9k are unsupported and customers should not use
>them :( And similar answer is from vendors who put these chips into
>their cards / products.

Is there a public statement that says that? Right now the MAINTAINERS
file says it's "supported" and if it's not the case we should at least
fix that and consider deprecating it if it's really orphaned.

-- 
Thanks,
Sasha

  reply	other threads:[~2021-08-20 21:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18  8:48 Backporting CVE-2020-3702 ath9k patches to stable Pali Rohár
2021-08-18  9:02 ` Greg KH
2021-08-18  9:10   ` Pali Rohár
2021-08-18  9:18     ` Greg KH
2021-08-20 11:35       ` Pali Rohár
2021-08-20 21:23         ` Sasha Levin [this message]
2021-08-20 22:27           ` Toke Høiland-Jørgensen
2021-08-20 23:07             ` Pali Rohár
2021-08-20 23:49             ` Sasha Levin
2021-08-20 22:41           ` Pali Rohár
2021-09-02 11:48       ` Pavel Machek
2021-09-02 12:02         ` Greg KH
2021-09-03  6:34           ` Pavel Machek
2021-09-06  8:49             ` Greg KH
2021-09-11  7:46               ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YSAdPJFhmTztd+0Z@sashalap \
    --to=sashal@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pali@kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).