[RFC] staging: nvec: possible missing bounds check in nvec_power_bat response handling

[RFC] staging: nvec: possible missing bounds check in nvec_power_bat response handling

[Lucas Jeffrey]

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.

Thanks, Lucas

Re: [RFC] staging: nvec: possible missing bounds check in nvec_power_bat response handling

[Greg Kroah-Hartman]

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.