Re: [PATCH v2] staging: nvec: validate battery response length before memcpy

[Greg KH <gregkh@linuxfoundation.org>]

On Sun, Mar 29, 2026 at 03:08:00PM -0600, Sebastian Josue Alba Vives wrote:
> From: Sebastián Alba Vives <sebasjosue84@gmail.com>
> 
> 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@gmx.de>
> Cc: stable@vger.kernel.org
> Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
> ---
> 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