Re: [PATCH] x86emul: V{,P}{COMPRESS,EXPAND}* can (wrongly) trigger assertion

On 16/07/2026 11:50 am, Jan Beulich wrote:
> On 16.07.2026 12:44, Andrew Cooper wrote:
>> On 16/07/2026 11:43 am, Jan Beulich wrote:
>>> AFL has pointed out that the op_bytes-is-not-0 assertion in common SIMD
>>> handling can trigger for these insns. Indeed when the (relevant part of)
>>> the controlling mask register is 0, no memory is accessed at all. Leave
>>> op_bytes unaltered in this case, to engage the short-circuiting in common
>>> SIMD handling when fault_suppression is true and op_bytes is 0.
>>>
>>> While there also correct a related typo in the test harness.
>>>
>>> Fixes: 65f82d4ce1ea ("x86emul: support AVX512{F,_VBMI2} compress/expand insns")
>>> Signed-off-by: Jan Beulich <[email protected]>
>> Acked-by: Andrew Cooper <[email protected]>
> Thanks.
>
>> Is this local AFL testing?  I'm slightly surprised that OSS-Fuzz hasn't
>> found this.
> Yes, I'm trying to remember to run the fuzzer every once in a while. Earlier
> runs of mine didn't spot the issue either. (I'm presently re-running things,
> to have a limited level of certainty that the issues it found are all sorted
> now. The other issues it found were in patches I continue to have pending.)

When I was doing AFL testing a while back, there was an ancillary
project which would take the fuzzing corpus (as it was being generated),
run it with a GCOV-enabled binary and produce an aggregate LCOV report
in real-time.

I did once get to 100% coverage, but it took AFL an awful long time to
find the final basic block, which was somewhere in the signed divide
path if memory serves.

If we want to get fancy, instead of using a single byte input as the
seed corpus, we could write out several which tickle the rarest paths. 
That ought to shorten the total time substantially.

~Andrew