Linux Tegra architecture development
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Lucas Jeffrey <luquijeffrey@gmail.com>
Cc: Marc Dietrich <marvin24@gmx.de>,
	linux-staging@lists.linux.dev, linux-tegra@vger.kernel.org
Subject: Re: [RFC] staging: nvec: possible missing bounds check in nvec_power_bat response handling
Date: Thu, 30 Jul 2026 07:58:16 +0200	[thread overview]
Message-ID: <2026073001-bunch-aloft-63f8@gregkh> (raw)
In-Reply-To: <CAObkL7OJBp1OkXud7cJvp-a5qA5ozZfE2Ee8j+w6XdfoXZ0z_g@mail.gmail.com>

On Thu, Jul 30, 2026 at 12:09:01AM -0300, Lucas Jeffrey wrote:
> Hello Marc, Greg,
> While reviewing drivers/staging/nvec/nvec_power.c I noticed that the
> battery response handler uses the length field from struct bat_response
> without validating it against the destination buffer size:
> nvec_power.c between lines 120 and 220:
> 
> static int nvec_power_bat_notifier(struct notifier_block *nb,
> unsigned long event_type, void *data)
> {
> struct nvec_power *power =
> container_of(nb, struct nvec_power, notifier);
> struct bat_response *res = data;
> (...)
> 
> switch (res->sub_type) { (...)
> case TYPE:
> memcpy(power->bat_type, &res->plc, res->length - 2); //res->length is never
> validated that is in a valid range, //according to the plc field in the
> bat_response struct it should be smaller than 30 (...)
> 
> }
> 
> return NOTIFY_STOP;
> }
> 
> 
> The same patterns patterns exist for MANUFACTURER and MODEL.
> My understanding is that res->length comes from the NVEC embedded
> controller response. If a malformed response contains a length larger than
> the destination buffer, this could result in an out-of-bounds write.
> I would like to confirm whether the NVEC protocol guarantees these length
> values, or whether the driver should validate them before copying.

The hardware should be trusted to send the correct data.

       reply	other threads:[~2026-07-30  5:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAObkL7OJBp1OkXud7cJvp-a5qA5ozZfE2Ee8j+w6XdfoXZ0z_g@mail.gmail.com>
2026-07-30  5:58 ` Greg Kroah-Hartman [this message]
2026-07-30  3:14 [RFC] staging: nvec: possible missing bounds check in nvec_power_bat response handling Lucas Jeffrey

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=2026073001-bunch-aloft-63f8@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=linux-tegra@vger.kernel.org \
    --cc=luquijeffrey@gmail.com \
    --cc=marvin24@gmx.de \
    /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