Hello Sasha and Greg!
Last week I sent request for backporting ath9k wifi fixes for security
issue CVE-2020-3702 into stable LTS kernels because Qualcomm/maintainers
did not it for more months... details are in email:
https://lore.kernel.org/stable/20210818084859.vcs4vs3yd6zetmyt@pali/t/#u
And now I got reports that in stable LTS kernels (4.14, 4.19) are
missing also other fixes for other Qualcomm wifi security issues,
covered by FragAttacks codename: CVE-2020-26145 CVE-2020-26139
CVE-2020-26141
People have already asked if somebody is already doing backports to 4.19
of patches for these security issues, but there was no response, see email:
https://lore.kernel.org/linux-wireless/[email protected]/
I got information that issues for ath10k are again going to be (or are
already?) fixed in some vendor custom/fork kernels, but not in official
stable tree 4.14/4.19 (yet).
This situation is really bad because lot of times I hear to use mainline
kernel versions or official stable LTS tree (which are maintained by
you), but due to such security issues in LTS trees which stays unfixed
and others say to use rather vendor custom/fork kernels where it is
claimed that issues are fixed.
And because there is no statement for end users (end users do not
communicate with vendors and so they do not have information what is
supported and what not), end users just use what Linux open source
distributions have in their kernels (which lot of times match official
LTS kernel trees). And users think that everything is OK and security
issues are fixed.
So there is really a need for public statement from you or Qualcomm
side, if stable LTS kernel trees are going to include security fixes for
drivers used by Qualcomm wifi chips (ath*k) or not or under which
conditions. And what should users / Linux distributions use if they do
not want to have years-old unpatched drivers with security issues. Such
information is really important also for distributions which include
unmodified (or slightly modified) kernel LTS trees into their own
packages. As they also need to know from which source should take
(e.g. Qualcomm wifi) drivers for their systems to ensure that have
security patches applied.
I can understand that you or other people or volunteers do not have time
to track or maintain some parts of drivers. So nothing wrong if official
statement is that stable trees X and Y do not receive security updates
for driver A and B anymore. Also I can understand that it takes some
time to include required fixes, so expect fixes for A and B in X and Y
versions with one month delay. But it is needed to know what should
people expect from LTS trees for particular drivers. Because I think it
is not currently clear...
Do not take me wrong, I just wanted to show that this is hidden problem
which needs some discussion.
On 8/23/21 7:08 AM, Pali Rohár wrote:
> Hello Sasha and Greg!
>
> Last week I sent request for backporting ath9k wifi fixes for security
> issue CVE-2020-3702 into stable LTS kernels because Qualcomm/maintainers
> did not it for more months... details are in email:
> https://lore.kernel.org/stable/20210818084859.vcs4vs3yd6zetmyt@pali/t/#u
For one thing, almost everyone using these radios is using openwrt or
similar which has its own patch sets.
So, it is good to have the patches backported to real kernels,
but also, for actual users of these, it matters more what openwrt
has done...
Thanks,
Ben
>
> And now I got reports that in stable LTS kernels (4.14, 4.19) are
> missing also other fixes for other Qualcomm wifi security issues,
> covered by FragAttacks codename: CVE-2020-26145 CVE-2020-26139
> CVE-2020-26141
>
> People have already asked if somebody is already doing backports to 4.19
> of patches for these security issues, but there was no response, see email:
> https://lore.kernel.org/linux-wireless/[email protected]/
>
> I got information that issues for ath10k are again going to be (or are
> already?) fixed in some vendor custom/fork kernels, but not in official
> stable tree 4.14/4.19 (yet).
>
> This situation is really bad because lot of times I hear to use mainline
> kernel versions or official stable LTS tree (which are maintained by
> you), but due to such security issues in LTS trees which stays unfixed
> and others say to use rather vendor custom/fork kernels where it is
> claimed that issues are fixed.
>
> And because there is no statement for end users (end users do not
> communicate with vendors and so they do not have information what is
> supported and what not), end users just use what Linux open source
> distributions have in their kernels (which lot of times match official
> LTS kernel trees). And users think that everything is OK and security
> issues are fixed.
>
> So there is really a need for public statement from you or Qualcomm
> side, if stable LTS kernel trees are going to include security fixes for
> drivers used by Qualcomm wifi chips (ath*k) or not or under which
> conditions. And what should users / Linux distributions use if they do
> not want to have years-old unpatched drivers with security issues. Such
> information is really important also for distributions which include
> unmodified (or slightly modified) kernel LTS trees into their own
> packages. As they also need to know from which source should take
> (e.g. Qualcomm wifi) drivers for their systems to ensure that have
> security patches applied.
>
> I can understand that you or other people or volunteers do not have time
> to track or maintain some parts of drivers. So nothing wrong if official
> statement is that stable trees X and Y do not receive security updates
> for driver A and B anymore. Also I can understand that it takes some
> time to include required fixes, so expect fixes for A and B in X and Y
> versions with one month delay. But it is needed to know what should
> people expect from LTS trees for particular drivers. Because I think it
> is not currently clear...
>
> Do not take me wrong, I just wanted to show that this is hidden problem
> which needs some discussion.
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Hi Ben,
On Tue, Aug 24, 2021 at 12:37 AM Ben Greear <[email protected]> wrote:
>
> On 8/23/21 7:08 AM, Pali Rohár wrote:
> > Hello Sasha and Greg!
> >
> > Last week I sent request for backporting ath9k wifi fixes for security
> > issue CVE-2020-3702 into stable LTS kernels because Qualcomm/maintainers
> > did not it for more months... details are in email:
> > https://lore.kernel.org/stable/20210818084859.vcs4vs3yd6zetmyt@pali/t/#u
>
> For one thing, almost everyone using these radios is using openwrt or
> similar which has its own patch sets.
For reference, according to Debian's own security tracker, only
CVE-2020-26139 is patched on all but the most ancient tracked release:
https://security-tracker.debian.org/tracker/CVE-2020-26139 (fixed in
all but the most ancient release)
https://security-tracker.debian.org/tracker/CVE-2020-3702 (all tracked
kernels are vulnerable)
https://security-tracker.debian.org/tracker/CVE-2020-26145 (only
testing/unstable is fixed)
https://security-tracker.debian.org/tracker/CVE-2020-26141 (only
testing/unstable is fixed)
Debian Buster has a 4.19 kernel and they only released Bullseye, it's
successor, a couple of weeks ago, so there's probably a
not-insignificant number of PCs out there still running kernels that
old, and I understand that they'll be supporting Buster with security
fixes for approximately another year:
https://www.debian.org/security/faq#lifespan
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
On Monday 23 August 2021 07:32:11 Ben Greear wrote:
> On 8/23/21 7:08 AM, Pali Rohár wrote:
> > Hello Sasha and Greg!
> >
> > Last week I sent request for backporting ath9k wifi fixes for security
> > issue CVE-2020-3702 into stable LTS kernels because Qualcomm/maintainers
> > did not it for more months... details are in email:
> > https://lore.kernel.org/stable/20210818084859.vcs4vs3yd6zetmyt@pali/t/#u
>
> For one thing, almost everyone using these radios is using openwrt or
> similar which has its own patch sets.
AFAIK, latest stable released openwrt uses ath9k from 4.19 tree and
AFAIK did not have above patch.
> So, it is good to have the patches backported to real kernels,
> but also, for actual users of these, it matters more what openwrt
> has done...
ath9k and ath10k wifi cards are widely used not only in wifi routers
(as access points) but also in laptops (as clients). These chips are
available on more (noname / laptop vendor branded) cards so are popular
also outside of openwrt market. Maybe people even do not know that their
wifi card in laptop has one of these Qualcomm chips.
> Thanks,
> Ben
>
> >
> > And now I got reports that in stable LTS kernels (4.14, 4.19) are
> > missing also other fixes for other Qualcomm wifi security issues,
> > covered by FragAttacks codename: CVE-2020-26145 CVE-2020-26139
> > CVE-2020-26141
> >
> > People have already asked if somebody is already doing backports to 4.19
> > of patches for these security issues, but there was no response, see email:
> > https://lore.kernel.org/linux-wireless/[email protected]/
> >
> > I got information that issues for ath10k are again going to be (or are
> > already?) fixed in some vendor custom/fork kernels, but not in official
> > stable tree 4.14/4.19 (yet).
> >
> > This situation is really bad because lot of times I hear to use mainline
> > kernel versions or official stable LTS tree (which are maintained by
> > you), but due to such security issues in LTS trees which stays unfixed
> > and others say to use rather vendor custom/fork kernels where it is
> > claimed that issues are fixed.
> >
> > And because there is no statement for end users (end users do not
> > communicate with vendors and so they do not have information what is
> > supported and what not), end users just use what Linux open source
> > distributions have in their kernels (which lot of times match official
> > LTS kernel trees). And users think that everything is OK and security
> > issues are fixed.
> >
> > So there is really a need for public statement from you or Qualcomm
> > side, if stable LTS kernel trees are going to include security fixes for
> > drivers used by Qualcomm wifi chips (ath*k) or not or under which
> > conditions. And what should users / Linux distributions use if they do
> > not want to have years-old unpatched drivers with security issues. Such
> > information is really important also for distributions which include
> > unmodified (or slightly modified) kernel LTS trees into their own
> > packages. As they also need to know from which source should take
> > (e.g. Qualcomm wifi) drivers for their systems to ensure that have
> > security patches applied.
> >
> > I can understand that you or other people or volunteers do not have time
> > to track or maintain some parts of drivers. So nothing wrong if official
> > statement is that stable trees X and Y do not receive security updates
> > for driver A and B anymore. Also I can understand that it takes some
> > time to include required fixes, so expect fixes for A and B in X and Y
> > versions with one month delay. But it is needed to know what should
> > people expect from LTS trees for particular drivers. Because I think it
> > is not currently clear...
> >
> > Do not take me wrong, I just wanted to show that this is hidden problem
> > which needs some discussion.
> >
>
>
> --
> Ben Greear <[email protected]>
> Candela Technologies Inc http://www.candelatech.com
Hi Pali,
On Mon, Aug 23, 2021 at 3:58 PM Pali Rohár <[email protected]> wrote:
>
> On Monday 23 August 2021 07:32:11 Ben Greear wrote:
> > On 8/23/21 7:08 AM, Pali Rohár wrote:
> > > Hello Sasha and Greg!
> > >
> > > Last week I sent request for backporting ath9k wifi fixes for security
> > > issue CVE-2020-3702 into stable LTS kernels because Qualcomm/maintainers
> > > did not it for more months... details are in email:
> > > https://lore.kernel.org/stable/20210818084859.vcs4vs3yd6zetmyt@pali/t/#u
> >
> > For one thing, almost everyone using these radios is using openwrt or
> > similar which has its own patch sets.
>
> AFAIK, latest stable released openwrt uses ath9k from 4.19 tree and
> AFAIK did not have above patch.
I think you asked for the following patches:
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")
And I can see they are already in the queue for next v4.19.y release,
so should be part of v4.19.205
--
Regards
Sudip
On Monday 23 August 2021 20:26:37 Sudip Mukherjee wrote:
> Hi Pali,
>
> On Mon, Aug 23, 2021 at 3:58 PM Pali Rohár <[email protected]> wrote:
> >
> > On Monday 23 August 2021 07:32:11 Ben Greear wrote:
> > > On 8/23/21 7:08 AM, Pali Rohár wrote:
> > > > Hello Sasha and Greg!
> > > >
> > > > Last week I sent request for backporting ath9k wifi fixes for security
> > > > issue CVE-2020-3702 into stable LTS kernels because Qualcomm/maintainers
> > > > did not it for more months... details are in email:
> > > > https://lore.kernel.org/stable/20210818084859.vcs4vs3yd6zetmyt@pali/t/#u
> > >
> > > For one thing, almost everyone using these radios is using openwrt or
> > > similar which has its own patch sets.
> >
> > AFAIK, latest stable released openwrt uses ath9k from 4.19 tree and
> > AFAIK did not have above patch.
>
> And I can see they are already in the queue for next v4.19.y release,
> so should be part of v4.19.205
Yes, I expect it. My point was that these patches were not available in
openwrt's custom patch sets about which Ben talked.
On Mon, Aug 23, 2021 at 04:08:44PM +0200, Pali Roh?r wrote:
> Hello Sasha and Greg!
>
> Last week I sent request for backporting ath9k wifi fixes for security
> issue CVE-2020-3702 into stable LTS kernels because Qualcomm/maintainers
> did not it for more months... details are in email:
> https://lore.kernel.org/stable/20210818084859.vcs4vs3yd6zetmyt@pali/t/#u
>
> And now I got reports that in stable LTS kernels (4.14, 4.19) are
> missing also other fixes for other Qualcomm wifi security issues,
> covered by FragAttacks codename: CVE-2020-26145 CVE-2020-26139
> CVE-2020-26141
Then someone needs to provide us backports if they care about these
very old kernels and these issues. Just like any other driver subsystem
where patches are not able to be easily backported.
Or just use a newer kernel, that's almost always a better idea.
thanks,
greg k-h
Greg KH <[email protected]> writes:
> On Mon, Aug 23, 2021 at 04:08:44PM +0200, Pali Rohár wrote:
>> Hello Sasha and Greg!
>>
>> Last week I sent request for backporting ath9k wifi fixes for security
>> issue CVE-2020-3702 into stable LTS kernels because Qualcomm/maintainers
>> did not it for more months... details are in email:
>> https://lore.kernel.org/stable/20210818084859.vcs4vs3yd6zetmyt@pali/t/#u
>>
>> And now I got reports that in stable LTS kernels (4.14, 4.19) are
>> missing also other fixes for other Qualcomm wifi security issues,
>> covered by FragAttacks codename: CVE-2020-26145 CVE-2020-26139
>> CVE-2020-26141
>
> Then someone needs to provide us backports if they care about these
> very old kernels and these issues. Just like any other driver subsystem
> where patches are not able to be easily backported.
>
> Or just use a newer kernel, that's almost always a better idea.
Sorry for the delay in my answer. But like Greg said, use of a newer
kernel is the best option. I don't have the bandwith to maintain ath[1]
drivers in stable releases, but I do try to make sure bugfixes have a
Fixes tag when approriate and I do add cc stable whenever people ask me
to. That's about it from stable releases point of view, my focus is on
Linus' releases.
Help with the stable releases is very welcome.
[1] ath9k, ath10k, ath11k etc
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches