The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: Xiang Mei <xmei5@asu.edu>, Bartosz Golaszewski <brgl@kernel.org>,
	Marcel Holtmann <marcel@holtmann.org>,
	Johan Hovold <johan+linaro@kernel.org>,
	linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org,
	bestswngs@gmail.com
Subject: Re: [PATCH bluetooth] Bluetooth: qca: fix NVM tag length underflow in TLV parser
Date: Thu, 9 Jul 2026 13:06:02 +0200	[thread overview]
Message-ID: <ak-AmguTdGpr04dm@hovoldconsulting.com> (raw)
In-Reply-To: <CABBYNZ+gp57kxcXZTLWgd5n19cmDc1Z8TimW0bv7CQLT7khzug@mail.gmail.com>

On Wed, Jul 08, 2026 at 11:15:00AM -0400, Luiz Augusto von Dentz wrote:
> On Wed, Jul 8, 2026 at 10:21 AM Johan Hovold <johan@kernel.org> wrote:
> > On Tue, Jul 07, 2026 at 10:55:23AM -0700, Xiang Mei wrote:
> > > On Sun, Jul 5, 2026 at 2:41 AM Johan Hovold <johan@kernel.org> wrote:
> > > > On Sat, Jul 04, 2026 at 04:10:30PM -0700, Xiang Mei wrote:

> > > > > The loop body
> > > > > then reads a 12-byte struct tlv_type_nvm past the end of the short
> > > > > vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it).
> > > >
> > > > No, only four bytes are read before the loop exits without any further
> > > > consequences due to the following check:
> >
> > > Thanks Johan, and you're right. Only the 2-byte tag_id (and at most
> > > the 4 bytes of tag_id/tag_len) is read out of bounds. This commit
> > > message overstated the impact, and I should have caught that.
> > >
> > > Unfortunately, the bot merged this patch when I was preparing the v2
> > > this morning. If you think the inaccurate commit message is worth
> > > fixing on record, I can send a follow-up to the maintainers to correct
> > > the message
> >
> > It was Luiz who applied the patch -- perhaps he did not notice my
> > conditional Reviewed-by tag.
> >
> > I assume the Bluetooth tree is not rebased so I don't think there's
> > anything that can be done here and there is no need to send a v2 (unless
> > Luiz says otherwise).
> 
> If only the commit message that needs updating then I guess we don't
> need to worry about if stating something slightly inaccurate.

It's mostly an issue for backporting and determining the impact of the
fix. The commit message as it stands suggests that the bug can result in
memory corruption when it really is just a 4-byte oob read.

And then the inclusion of my tag makes it look like I failed to spot
this during review.

But let's keep it this way this time.

Johan

  reply	other threads:[~2026-07-09 11:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-04 23:10 [PATCH bluetooth] Bluetooth: qca: fix NVM tag length underflow in TLV parser Xiang Mei
2026-07-05  9:41 ` Johan Hovold
2026-07-07 17:55   ` Xiang Mei
2026-07-08 14:21     ` Johan Hovold
2026-07-08 15:15       ` Luiz Augusto von Dentz
2026-07-09 11:06         ` Johan Hovold [this message]
2026-07-06  9:39 ` Bartosz Golaszewski
2026-07-07 17:30 ` patchwork-bot+bluetooth

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=ak-AmguTdGpr04dm@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=bestswngs@gmail.com \
    --cc=brgl@kernel.org \
    --cc=johan+linaro@kernel.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    --cc=xmei5@asu.edu \
    /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