"Christian A. Ehrhardt" <l...@c--e.de> writes:
> Hi Markus,
>
> On Thu, Oct 20, 2022 at 08:14:32AM +0200, Markus Armbruster wrote:
>> "Christian A. Ehrhardt" <l...@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.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>
>> > /* 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?
