Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 18 Aug 2021 11:10:27 +0200
From:   Pali =?utf-8?B?Um9ow6Fy?= <pali@kernel.org>
To:     Greg KH <gregkh@linuxfoundation.org>
Cc:     stable@vger.kernel.org, Sasha Levin <sashal@kernel.org>,
        Kalle Valo <kvalo@codeaurora.org>,
        linux-wireless@vger.kernel.org
Subject: Re: Backporting CVE-2020-3702 ath9k patches to stable
Message-ID: <20210818091027.2mhqrhg5pcq2bagt@pali>
References: <20210818084859.vcs4vs3yd6zetmyt@pali>
 <YRzMt53Ca/5irXc0@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <YRzMt53Ca/5irXc0@kroah.com>
User-Agent: NeoMutt/20180716
Precedence: bulk

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).

> thanks,
> 
> greg k-h