From: Francesco Dolcini <francesco@dolcini.it>
To: Johannes Berg <johannes@sipsolutions.net>, skyexpoc <skyexpoc@gmail.com>
Cc: Francesco Dolcini <francesco@dolcini.it>,
Brian Norris <briannorris@chromium.org>,
Miri Korenblit <miriam.rachel.korenblit@intel.com>,
Kalle Valo <kvalo@kernel.org>, Kees Cook <kees@kernel.org>,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] wifi: mwifiex: bound uAP association event IEs to the event buffer
Date: Fri, 10 Jul 2026 16:23:07 +0200 [thread overview]
Message-ID: <20260710142307.GA77999@francesco-nb> (raw)
In-Reply-To: <8b98582b-1120-46ff-8fa6-fd30a6b13016@Canary> <1462bcdb0944bfd3ae7ac9618cc59ab6cf75dfc6.camel@sipsolutions.net>
On Fri, Jul 10, 2026 at 09:41:26AM +0200, Johannes Berg wrote:
> On Fri, 2026-07-10 at 09:21 +0200, Francesco Dolcini wrote:
> > I think we received a few patches that are validating the data received
> > from the firmware (including this one).
> >
> > I did not review any of them yet, what is your opinion on those?
> >
> > Should we consider the firmware trust-worth or should we validate
> > everything we receive from it? Is there some agreement on this topic in
> > general?
>
> I don't really know fully "in general", but I/we generally treat these
> as issues. I'm not going to worry too much about them, but I think we
> should fix them.
Ack
On Fri, Jul 10, 2026 at 07:44:27PM +0900, skyexpoc wrote:
> > Should we consider the firmware trust-worthy or should we validate
> > everything we receive from it? Is there some agreement on this topic
> > in general?
>
> For mwifiex there's a concrete reason not to trust it: besides the
> SDIO/PCIe parts, mwifiex also drives USB dongles (8797/8801/8997), so the
> "firmware" can sit on a hot-pluggable, potentially attacker-supplied
> device. A malformed event from such a device is the same threat model as
> any other malicious USB peripheral, not just a hypothetical firmware bug.
...
> So I'd say it's consistent with how the driver already treats
> firmware-reported lengths and agreed, worth fixing.
... and ack.
Johannes, Brian: I will try to review those patches, unless someone
gets to them earlier and they are merged.
Francesco
prev parent reply other threads:[~2026-07-10 14:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 12:03 [PATCH] wifi: mwifiex: bound uAP association event IEs to the event buffer HE WEI (ギカク)
2026-07-10 7:21 ` Francesco Dolcini
2026-07-10 7:41 ` Johannes Berg
2026-07-10 10:44 ` skyexpoc
2026-07-10 14:23 ` Francesco Dolcini [this message]
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=20260710142307.GA77999@francesco-nb \
--to=francesco@dolcini.it \
--cc=briannorris@chromium.org \
--cc=johannes@sipsolutions.net \
--cc=kees@kernel.org \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=miriam.rachel.korenblit@intel.com \
--cc=skyexpoc@gmail.com \
/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 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.