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.
next parent 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