Re: [PATCH] hw/acpi/erst.c: Fix memset argument order

[Alexander Bulekov]

On 221019 2115, Christian A. Ehrhardt wrote:
> Fix memset argument order: The second argument is
> the value, the length goes last.
> 
> Cc: Eric DeVolder <eric.devolder@oracle.com>
> Cc: qemu-stable@nongnu.org
> Fixes: f7e26ffa590 ("ACPI ERST: support for ACPI ERST feature")
> Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
> ---
>  hw/acpi/erst.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/acpi/erst.c b/hw/acpi/erst.c
> index df856b2669..26391f93ca 100644
> --- a/hw/acpi/erst.c
> +++ b/hw/acpi/erst.c
> @@ -716,7 +716,7 @@ static unsigned write_erst_record(ERSTDeviceState *s)
>      if (nvram) {
>          /* Write the record into the slot */
>          memcpy(nvram, exchange, record_length);
> -        memset(nvram + record_length, exchange_length - record_length, 0xFF);
> +        memset(nvram + record_length, 0xFF, exchange_length - record_length);

Hi, 
I'm running the fuzzer over this code. So far, it hasn't complained
about this particular memset call, but it has crashed on the memcpy,
directly preceding it. I think the record_length checks might be
insufficient. I made an issue/reproducer:
https://gitlab.com/qemu-project/qemu/-/issues/1268

In that particular case, record_length is ffffff00 and passes the
checks. I'll keep an eye on the fuzzer to see if it will be able to
crash the memset.

For this patch:
Reviewed-by: Alexander Bulekov <alxndr@bu.edu>

>          /* If a new record, increment the record_count */
>          if (!record_found) {
>              uint32_t record_count;
> -- 
> 2.34.1
> 
>