linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Ben Greear <greearb@candelatech.com>
Cc: Sasha Levin <sashal@kernel.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, linux-wireless@vger.kernel.org
Subject: Re: Drivers for Qualcomm wifi chips (ath*k) and security issues
Date: Mon, 23 Aug 2021 16:58:00 +0200	[thread overview]
Message-ID: <20210823145800.4vzdgzjch77ldeku@pali> (raw)
In-Reply-To: <18c5a8be-66d7-0dd8-b158-0931335f7ac5@candelatech.com>

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/704e1c77-6c48-79f7-043a-b2d03fbfef8b@candelatech.com/
> > 
> > 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 <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com

  parent reply	other threads:[~2021-08-23 14:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-23 14:08 Drivers for Qualcomm wifi chips (ath*k) and security issues Pali Rohár
2021-08-23 14:32 ` Ben Greear
2021-08-23 14:54   ` Julian Calaby
2021-08-23 14:58   ` Pali Rohár [this message]
2021-08-23 19:26     ` Sudip Mukherjee
2021-08-23 20:02       ` Pali Rohár
2021-08-23 19:04 ` Greg KH
2021-10-11 10:41   ` Kalle Valo

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=20210823145800.4vzdgzjch77ldeku@pali \
    --to=pali@kernel.org \
    --cc=greearb@candelatech.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=sashal@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).