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