Re: [PATCH v2] staging: nvec: validate battery response length before memcpy
From: Greg KH
Date: Mon Mar 30 2026 - 01:49:49 EST
On Sun, Mar 29, 2026 at 03:08:00PM -0600, Sebastian Josue Alba Vives wrote:
> From: Sebastián Alba Vives <sebasjosue84@xxxxxxxxx>
>
> In nvec_power_notifier(), the response length from the embedded
> controller is used directly as the size argument to memcpy() when
> copying battery manufacturer, model, and type strings. The
> destination buffers (bat_manu, bat_model, bat_type) are fixed at
> 30 bytes, but res->length is a u8 that can be up to 255, allowing
> a heap buffer overflow.
>
> Additionally, if res->length is less than 2, the subtraction
> res->length - 2 wraps around as an unsigned value, resulting in a
> large copy that corrupts kernel heap memory.
>
> Introduce NVEC_BAT_STRING_SIZE to replace the hardcoded buffer
> size, store res->length - 2 in a local copy_len variable for
> clarity, and add bounds checks before each memcpy to ensure the
> copy length does not exceed the destination buffer and that
> res->length is at least 2 to prevent unsigned integer underflow.
>
> Tested-by: Marc Dietrich <marvin24@xxxxxx>
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Sebastián Alba Vives <sebasjosue84@xxxxxxxxx>
> ---
> v2:
> - Introduce NVEC_BAT_STRING_SIZE constant to replace hardcoded
> buffer size (Marc Dietrich)
> - Store res->length - 2 in local copy_len variable for clarity
> (Marc Dietrich)
> - Use NVEC_BAT_STRING_SIZE in strncmp call for consistency
> drivers/staging/nvec/nvec_power.c | 41 +++++++++++++++++++++----------
> 1 file changed, 28 insertions(+), 13 deletions(-)
Is there a reason you are not sending these to the staging maintainer
and mailing list so that they can actually be applied?
thanks,
greg k-h