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

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