Re: [RFC] staging: nvec: possible missing bounds check in nvec_power_bat response handling
Greg Kroah-Hartman <[email protected]> Thu, 30 Jul 2026 07:58:16 +0200
| Newsgroups | org.kernel.vger.linux-tegra,dev.linux.lists.linux-staging |
|---|---|
| Message-ID | <2026073001-bunch-aloft-63f8@gregkh> |
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.