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

[Christian A. Ehrhardt]

On Fri, Oct 21, 2022 at 06:22:50AM +0200, Markus Armbruster wrote:
> "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?

Yes, it is taken from the CPER header in the exchange store.

     regards   Christian