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

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
- Hypervisor vendor: Xen

Main machine:
- x86_64, AMD Ryzen 9 7950X


Also I think I'll also wait for you to make the relevant changes & then
apply the patches locally.


Question seeking advice:
I've been trying to find low-hanging fruit issues within Xen to try and
fix, I currently have a fuzzer running for cpu-policy. It would be nice to
get some pointers on where/what to look for.


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?
>
> > If the fuzzer then generates & feeds an instruction containing AVX,the
> emulator
> > attempts to fetch the FPU state via x86emul_get_fpu(), which then calls
> emul_test_read_xcr() and hits the ASSERT(cpu_has_xsave). This assertion
> crashes the fuzzer.
> >
> > The crash:
> > 1. $ ./afl-harness < findings_dir/master01/...
> >    afl-harness: ../../tests/x86_emulator/x86-emulate.c:179:
> emul_test_read_xcr: Assertion `cpu_has_xsave' failed.
> >    Aborted
> >
> > 2. The stacktrace:
> > (gdb) bt
> > data_p=data_p@entry=0x55555604f320 <input>
> "\244\264\336\346\337\001\254%\247R\216d\204*\234\377\377\224λ\3237/\365ʿX\266?\353\036\227/\0323\351dj\257\v\207\031V֖\235{\036\225|:M\330\336
> \314V:&\357\306@\224\331,\301\300\372FW\262.\020\\\276\244\203\242\276\262\022!\337)F&\261\2064\200\200\377I;J\376X41\2061\206\325
> \021\017F\026\267\275\340\361\357)\255\343\237n\377\374n\357#ֽ\226\365d",
> > size=size@entry=580) at fuzz-emul.c:934
>
> This can't be the complete stack trace.
>
> > Possible fixes:
> > To prevent the fuzzer from getting stuck on this state,would it be
> better for emul_test_read_xcr to return X86EMUL_UNHANDLEABLE (or something
> similar) instead of ASSERT(cpu_has_xsave) ?
>
> No, I think the assertion is legitimate there. After sending this reply,
> I'll
> post two patches taken off of the (unposted) APX series I have pending,
> which
> I think get things into better shape (and which, with the minor editing I
> had
> to do to pull them out of that series, should be fine to move ahead). On
> top
> of that we then will want to add some sanitization of input state in the
> fuzzing harness: CR4.OSXSAVE set and CPUID.XSAVE clear are clearly
> contradictory. There are other impossible combinations, and I think we may
> want to address some of them at the same time, and we already have
> sanitize_input() there. Please let us know whether you'd be willing /
> interested to make changes there, or whether we (perhaps I) should.
>
> Jan
>