While running the x86_instruction_emulator fuzzer via AFL, I encountered an assertion failure in the emul_test_read_xcr() function.
The fuzzer is able to generate a CPU state where cpu_has_xsave is false. 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

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) ?

I have attached the binary crash file(converted to Base64) found by AFL below:

pLTe5t8BrCWnUo5khCqc//+UzrvTNy/1yr9Ytj/rHpcvGjPpZGqvC4cZVtaWnXselXw6TdjeIMxW
OibvxkCU2SzBwPpGV7IuEFy+pIOivrISId8pRiaxhjSAgP9JO0r+WDQxhjGG1SARD0YWt73g8e8p
reOfbv/8bu8j1r2W9WQAJnNNzsTXiDzn+tIYXP5ib7u5oA9GFre94PHvKa3jn27N/G7vI9a9lvVk
f/9fO1wsISMXjMG1qMtVHNLp6uRBZb1cV0Ybc1T5SBvfAawlp1KOZIQqnP//lOi70zgv9cq/WPWk
5MOmSoAqmv+M1R9Sc8UnJgEA9fX1IvX19fXu9fX19fX19fX19fX1/+dKZ6S03ubfAawlv1j1pOTD
pkqAKpr/jDcv9cq/WLY/6x6XLxoz6WRrrguGGVbWlsD6RleQLuUQkKSDoqayEiHf1kYmsYY0gFPE
gP9JO0r+VzQxhtUgEdeIPOf60hhcBmJvu7mgD0YWt73g8e8preOfbv/8bu/c1sbQS2L9zkVE9Ohz
xScmAQD19fUi9fVfO1xJAAACAMG1qMtVHNLp6uRBZX+AAAAbc1TaSBsdNdgkffrwwtCPjXe/D62n
Z+mGpLTe5t8BrCWnUo5khCqc//+UzrvTNy/1yr9Ytj/rHpcvGjPpZGuuC4cZVtaWnXselXw6TQAP
f/9WOibvxpCU2SzBwPpGV7IuEFy+pIOivrISId8pRiaxhjSAZWVlZWVlZWVlZWVlZWVlZWJlZWVl
ZWVleGVlZWVlZQ==

Signed-off-by: Andrew Mbugua <andrewprecious388@gmail.com>
---
 tools/tests/x86_emulator/x86-emulate.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/tests/x86_emulator/x86-emulate.c b/tools/tests/x86_emulator/x86-emulate.c
index e2fbeb52e7..4d0b4610b5 100644
--- a/tools/tests/x86_emulator/x86-emulate.c
+++ b/tools/tests/x86_emulator/x86-emulate.c
@@ -176,7 +176,8 @@ int emul_test_read_xcr(
 {
     uint32_t lo, hi;
 
-    ASSERT(cpu_has_xsave);
+    if ( !cpu_has_xsave )
+	return X86EMUL_UNHANDLEABLE;
 
     switch ( reg )
     {
-- 
2.47.3

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

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@suse.com> 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
>

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 <jbeulich@suse.com> 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

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 <jbeulich@suse.com> 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 <jbeulich@suse.com> 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
>