Re: [BUG] x86emul/test: avoid assertion in emul_test_read_xcr() when XSAVE is absent

My thinking before was that the fuzzer mutated some bytes that made the
emulator think cpu_has_xsave was false.

But now I believe that this was caused by an environment issue caused by
the default QEMU virtual cpu model.

The VM has no OSXSAVE flag(but the host does), x86_cpu_policy_fill_native()
initializes with the OSXSAVE bit cleared,hits the assert(cpu_has_xsave)
which then aborts the fuzzer.

On Thu, Aug 20, 2026 at 5:13 PM Jan Beulich <[email protected]> wrote:

> On 20.08.2026 14:30, Andrew Precious wrote:
> > I just realized that I attached the binary result without the fuzzer
> error.
> > To generate the previous assertion error I would have to rerun the fuzzer
> > again which took many hours(~18hrs). Though that was the only error I
> found
> > after that long.
> >
> > VM machine that I performed the fuzzing on:
> > - A VM running Debian GNU/Linux 13 (trixie)
> > - x86_64,QEMU Virtual CPU version 2.5
>
> What does that mean CPUID-wise, seeing that ...
>
> > On Thu, Aug 20, 2026 at 11:45 AM Jan Beulich <[email protected]> wrote:
> >> On 19.08.2026 20:07, Andrew Mbugua wrote:
> >>> While running the x86_instruction_emulator fuzzer via AFL, I
> encountered
> >> an assertion failure in the emul_test_read_xcr() function.
> >>
> >> Thanks for the report.
> >>
> >>> The fuzzer is able to generate a CPU state where cpu_has_xsave is
> false.
> >>
> >> I'm having trouble here: cpu_policy isn't populated from fuzzing input,
> and
> >>
> >> /* Intentionally checking OSXSAVE here. */
> >> #define cpu_has_xsave     (cpu_policy.basic.raw[1].c & (1u << 27))
> >>
> >> would mean that upon filling cpu_policy (emul_test_init() ->
> >> x86_cpu_policy_fill_native()) the OSXSAVE bit would be clear. Are you
> >> suggesting you did the fuzzing on some really old hardware?
>
> ... there was this aspect that I couldn't understand?
>
> Jan
>