On Fri, Oct 21, 2022 at 06:22:50AM +0200, Markus Armbruster wrote:
> "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?
Yes, it is taken from the CPER header in the exchange store.
regards Christian
