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.devol...@oracle.com>
> Cc: qemu-sta...@nongnu.org
> Fixes: f7e26ffa590 ("ACPI ERST: support for ACPI ERST feature")
> Signed-off-by: Christian A. Ehrhardt <l...@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 <alx...@bu.edu>
> /* If a new record, increment the record_count */
> if (!record_found) {
> uint32_t record_count;
> --
> 2.34.1
>
>
