All of lore.kernel.org
 help / color / mirror / Atom feed
* Backporting CVE-2020-3702 ath9k patches to stable
@ 2021-08-18  8:48 Pali Rohár
  2021-08-18  9:02 ` Greg KH
  0 siblings, 1 reply; 15+ messages in thread
From: Pali Rohár @ 2021-08-18  8:48 UTC (permalink / raw)
  To: stable; +Cc: Greg KH, Sasha Levin, Kalle Valo, linux-wireless

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Backporting CVE-2020-3702 ath9k patches to stable
  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
  0 siblings, 1 reply; 15+ messages in thread
From: Greg KH @ 2021-08-18  9:02 UTC (permalink / raw)
  To: Pali Rohár; +Cc: stable, Sasha Levin, Kalle Valo, linux-wireless

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?

And what order are the above commits to be applied in, top-to-bottom or
bottom-to-top?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Backporting CVE-2020-3702 ath9k patches to stable
  2021-08-18  9:02 ` Greg KH
@ 2021-08-18  9:10   ` Pali Rohár
  2021-08-18  9:18     ` Greg KH
  0 siblings, 1 reply; 15+ messages in thread
From: Pali Rohár @ 2021-08-18  9:10 UTC (permalink / raw)
  To: Greg KH; +Cc: stable, Sasha Levin, Kalle Valo, linux-wireless

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Backporting CVE-2020-3702 ath9k patches to stable
  2021-08-18  9:10   ` Pali Rohár
@ 2021-08-18  9:18     ` Greg KH
  2021-08-20 11:35       ` Pali Rohár
  2021-09-02 11:48       ` Pavel Machek
  0 siblings, 2 replies; 15+ messages in thread
From: Greg KH @ 2021-08-18  9:18 UTC (permalink / raw)
  To: Pali Rohár; +Cc: stable, Sasha Levin, Kalle Valo, linux-wireless

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Backporting CVE-2020-3702 ath9k patches to stable
  2021-08-18  9:18     ` Greg KH
@ 2021-08-20 11:35       ` Pali Rohár
  2021-08-20 21:23         ` Sasha Levin
  2021-09-02 11:48       ` Pavel Machek
  1 sibling, 1 reply; 15+ messages in thread
From: Pali Rohár @ 2021-08-20 11:35 UTC (permalink / raw)
  To: Greg KH; +Cc: stable, Sasha Levin, Kalle Valo, linux-wireless

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Backporting CVE-2020-3702 ath9k patches to stable
  2021-08-20 11:35       ` Pali Rohár
@ 2021-08-20 21:23         ` Sasha Levin
  2021-08-20 22:27           ` Toke Høiland-Jørgensen
  2021-08-20 22:41           ` Pali Rohár
  0 siblings, 2 replies; 15+ messages in thread
From: Sasha Levin @ 2021-08-20 21:23 UTC (permalink / raw)
  To: Pali Rohár; +Cc: Greg KH, stable, Kalle Valo, linux-wireless

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Backporting CVE-2020-3702 ath9k patches to stable
  2021-08-20 21:23         ` Sasha Levin
@ 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
  1 sibling, 2 replies; 15+ messages in thread
From: Toke Høiland-Jørgensen @ 2021-08-20 22:27 UTC (permalink / raw)
  To: Sasha Levin, Pali Rohár; +Cc: Greg KH, stable, Kalle Valo, linux-wireless

Sasha Levin <sashal@kernel.org> writes:

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

FWIW there's still quite a few OpenWrt devices that are using ath9k and
ticking away happily. And we are some that do still care about ath9k,
even if QCA doesn't... As the email that started this thread also shows,
I suppose?

-Toke


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Backporting CVE-2020-3702 ath9k patches to stable
  2021-08-20 21:23         ` Sasha Levin
  2021-08-20 22:27           ` Toke Høiland-Jørgensen
@ 2021-08-20 22:41           ` Pali Rohár
  1 sibling, 0 replies; 15+ messages in thread
From: Pali Rohár @ 2021-08-20 22:41 UTC (permalink / raw)
  To: Sasha Levin; +Cc: Greg KH, stable, Kalle Valo, linux-wireless

On Friday 20 August 2021 17:23:08 Sasha Levin wrote:
> 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.

No, there is no public statement. This is just (private) response from
official Qualcomm support contact...

And from card vendors were similar replies, that they received only fix
from Qualcomm (for proprietary driver) and for open source ath9k support
I need to ask open source kernel community. They suggested me to wait
until open source kernel community fix it.

I really do not know what is the support state of ath9k, but the fact is
that this security issue was fixed in July 2020 (in Qualcomm driver) and
some vendors received fix even earlier.

So something is really wrong if in LTS kernels this issue was not fixed
for more than year and in vendor driver was it basically immediately.

I agree that some clarification or public statement about ath9k driver
support would be very useful...

> -- 
> Thanks,
> Sasha

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Backporting CVE-2020-3702 ath9k patches to stable
  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
  1 sibling, 0 replies; 15+ messages in thread
From: Pali Rohár @ 2021-08-20 23:07 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen
  Cc: Sasha Levin, Greg KH, stable, Kalle Valo, linux-wireless

On Saturday 21 August 2021 00:27:10 Toke Høiland-Jørgensen wrote:
> Sasha Levin <sashal@kernel.org> writes:
> 
> > 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.
> 
> FWIW there's still quite a few OpenWrt devices that are using ath9k and
> ticking away happily. And we are some that do still care about ath9k,
> even if QCA doesn't... As the email that started this thread also shows,
> I suppose?

For sure, there are lot of people who are using cards with this driver.
These cards are still popular for scenarios where 802.11N is enough as
these chips are relatively stable and have good hw design. In these
chips there is no CPU, no DSP, everything is done directly in HW or on
host CPU (in kernel driver or userspace). So therefore there is no
firmware/microcode like in new cards single point of failure or cause
instability. And card vendors are still putting these chips also into
new cards.

Simple issues (like kernel crash, API change, ... ) in ath9k driver can
be relatively easily fixed by (any) kernel developer. But issues like
fixing some cryptography part used in hw chip does not have to be simple
for people who do not have HW documentation or are not skilled in how
chip is working. (IIRC there is no public HW documentation)

So due to popularity basic maintenance is and would be still there (even
without Qualcomm support), but security related issues are problematic.

And I think that these older wifi cards would be still under attack by
security researchers. So we can expect that in future there can be
another attack which would need some driver modification for correct
mitigation...

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Backporting CVE-2020-3702 ath9k patches to stable
  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
  1 sibling, 0 replies; 15+ messages in thread
From: Sasha Levin @ 2021-08-20 23:49 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen
  Cc: Pali Rohár, Greg KH, stable, Kalle Valo, linux-wireless

On Sat, Aug 21, 2021 at 12:27:10AM +0200, Toke Høiland-Jørgensen wrote:
>Sasha Levin <sashal@kernel.org> writes:
>> On Fri, Aug 20, 2021 at 01:35:05PM +0200, Pali Rohár wrote:
>>>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.
>
>FWIW there's still quite a few OpenWrt devices that are using ath9k and
>ticking away happily. And we are some that do still care about ath9k,
>even if QCA doesn't... As the email that started this thread also shows,
>I suppose?

Thats obviously true, and if there are people who care about this then
they should both get the tools needed from the community to do their
work as well as the credit for getting the work done.

-- 
Thanks,
Sasha

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Backporting CVE-2020-3702 ath9k patches to stable
  2021-08-18  9:18     ` Greg KH
  2021-08-20 11:35       ` Pali Rohár
@ 2021-09-02 11:48       ` Pavel Machek
  2021-09-02 12:02         ` Greg KH
  1 sibling, 1 reply; 15+ messages in thread
From: Pavel Machek @ 2021-09-02 11:48 UTC (permalink / raw)
  To: Greg KH, nobuhiro1.iwamatsu
  Cc: Pali Rohár, stable, Sasha Levin, Kalle Valo, linux-wireless

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

Hi!

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

...

> Great, all now queued up.  Sad that qcom didn't want to do this
> themselves :(

Thanks for the fixes; I see them in 4.14 and newer stable trees.

But I don't see them in 4.4 and 4.9, nor can I see reason why they
were not applied.

Can someone help?

Thanks,
								Pavel
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Backporting CVE-2020-3702 ath9k patches to stable
  2021-09-02 11:48       ` Pavel Machek
@ 2021-09-02 12:02         ` Greg KH
  2021-09-03  6:34           ` Pavel Machek
  0 siblings, 1 reply; 15+ messages in thread
From: Greg KH @ 2021-09-02 12:02 UTC (permalink / raw)
  To: Pavel Machek
  Cc: nobuhiro1.iwamatsu, Pali Rohár, stable, Sasha Levin,
	Kalle Valo, linux-wireless

On Thu, Sep 02, 2021 at 01:48:14PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > 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/
> ...
> > > > 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
> 
> ...
> 
> > Great, all now queued up.  Sad that qcom didn't want to do this
> > themselves :(
> 
> Thanks for the fixes; I see them in 4.14 and newer stable trees.
> 
> But I don't see them in 4.4 and 4.9, nor can I see reason why they
> were not applied.
> 
> Can someone help?

Odd, I don't remember why I didn't even try to apply them to older
kernels.  I'll do that after this next round is released in a few days,
sorry about that.

greg k-h

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Backporting CVE-2020-3702 ath9k patches to stable
  2021-09-02 12:02         ` Greg KH
@ 2021-09-03  6:34           ` Pavel Machek
  2021-09-06  8:49             ` Greg KH
  0 siblings, 1 reply; 15+ messages in thread
From: Pavel Machek @ 2021-09-03  6:34 UTC (permalink / raw)
  To: Greg KH
  Cc: Pavel Machek, nobuhiro1.iwamatsu, Pali Rohár, stable,
	Sasha Levin, Kalle Valo, linux-wireless

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

Hi!

> > > > > > See also:
> > > > > > https://lore.kernel.org/linux-wireless/87o8hvlx5g.fsf@codeaurora.org/
> > ...
> > > > > 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
> > 
> > ...
> > 
> > > Great, all now queued up.  Sad that qcom didn't want to do this
> > > themselves :(
> > 
> > Thanks for the fixes; I see them in 4.14 and newer stable trees.
> > 
> > But I don't see them in 4.4 and 4.9, nor can I see reason why they
> > were not applied.
> > 
> > Can someone help?
> 
> Odd, I don't remember why I didn't even try to apply them to older
> kernels.  I'll do that after this next round is released in a few days,
> sorry about that.

Thank you! If there are problems, let me know and I'll try to help.

Best regards,
								Pavel
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Backporting CVE-2020-3702 ath9k patches to stable
  2021-09-03  6:34           ` Pavel Machek
@ 2021-09-06  8:49             ` Greg KH
  2021-09-11  7:46               ` Pavel Machek
  0 siblings, 1 reply; 15+ messages in thread
From: Greg KH @ 2021-09-06  8:49 UTC (permalink / raw)
  To: Pavel Machek
  Cc: nobuhiro1.iwamatsu, Pali Rohár, stable, Sasha Levin,
	Kalle Valo, linux-wireless

On Fri, Sep 03, 2021 at 08:34:40AM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > > > See also:
> > > > > > > https://lore.kernel.org/linux-wireless/87o8hvlx5g.fsf@codeaurora.org/
> > > ...
> > > > > > 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
> > > 
> > > ...
> > > 
> > > > Great, all now queued up.  Sad that qcom didn't want to do this
> > > > themselves :(
> > > 
> > > Thanks for the fixes; I see them in 4.14 and newer stable trees.
> > > 
> > > But I don't see them in 4.4 and 4.9, nor can I see reason why they
> > > were not applied.
> > > 
> > > Can someone help?
> > 
> > Odd, I don't remember why I didn't even try to apply them to older
> > kernels.  I'll do that after this next round is released in a few days,
> > sorry about that.
> 
> Thank you! If there are problems, let me know and I'll try to help.

Now all queued up.

greg k-h

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Backporting CVE-2020-3702 ath9k patches to stable
  2021-09-06  8:49             ` Greg KH
@ 2021-09-11  7:46               ` Pavel Machek
  0 siblings, 0 replies; 15+ messages in thread
From: Pavel Machek @ 2021-09-11  7:46 UTC (permalink / raw)
  To: Greg KH
  Cc: Pavel Machek, nobuhiro1.iwamatsu, Pali Rohár, stable,
	Sasha Levin, Kalle Valo, linux-wireless

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

Hi!

> > > Odd, I don't remember why I didn't even try to apply them to older
> > > kernels.  I'll do that after this next round is released in a few days,
> > > sorry about that.
> > 
> > Thank you! If there are problems, let me know and I'll try to help.
> 
> Now all queued up.

Thank you! One less CVE to watch.

Best regards,

								Pavel
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2021-09-11  7:55 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.