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

[Andrew Precious <andrewprecious388@xxxxxxxxx>]

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 <jbeulich@xxxxxxxx> 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