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

[Markus Armbruster]

"Christian A. Ehrhardt" <lk@c--e.de> writes:

> Hi Markus,
>
> On Thu, Oct 20, 2022 at 08:14:32AM +0200, Markus Armbruster wrote:
>> "Christian A. Ehrhardt" <lk@c--e.de> writes:
>> 
>> > Fix memset argument order: The second argument is
>> > the value, the length goes last.
>> 
>> Impact of the bug?
>
> Well, this is a memory error, i.e. the potential impact is
> anything from silent data corruption to arbitrary code execution.
> Phillipe described this accurately as "Ouch".
>
>> > 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>
>> >          /* Write the record into the slot */
>
> [ ... ]
>
>> This first copies @record_length bytes into the exchange buffer.
>> 
>> > -        memset(nvram + record_length, exchange_length - record_length, 
>> > 0xFF);
>> > +        memset(nvram + record_length, 0xFF, exchange_length - 
>> > record_length);
>> 
>> The new code pads it to the full exchange buffer size.
>> 
>> The old code writes 0xFF bytes.
>> 
>> If 0xFF < exchange_length - record_length, the padding doesn't extend to
>> the end of the buffer.  Impact?
>
> Incorrect and insufficient data is written.
>
>> If 0xFF > exchange_length - record_length, we write beyond the end of
>> the buffer.  Impact?
>
> Buffer overrun with well known potentially catastrophic consequences.
> Additionally, incorrect data is used for the padding.

Is record_length controlled by the guest?