strange segfault i386-dis.c:9815:28

[Jan Beulich]

On 23.03.2023 13:59, Alan Modra wrote:
> On Mon, Mar 20, 2023 at 11:41:08AM +0100, Jan Beulich wrote:
>> On 20.03.2023 11:26, Alan Modra wrote:
>>> On Mon, Mar 20, 2023 at 06:27:20PM +1030, Alan Modra wrote:
>>>> On Mon, Mar 20, 2023 at 08:29:44AM +0100, Jan Beulich wrote:
>>>>> Does this actually go far enough? Functions called may be inlined, and
>>>>> hence further accesses of struct fields held in registers may occur.
>>>>
>>>> I think we are OK.  The fields accessed are ins.address_mode and
>>>> ins.info, which are set up early in print_insn and read-only past the
>>>> setjmp.
>>>
>>> Perhaps you are correct that my change doesn't go far enough for a
>>> different reason.  Accessing these local var structs using a volatile
>>> qualified pointer may indeed read the object, but I don't think
>>> changed values are guaranteed to be written back to the object unless
>>> the actual object is declared volatile.
>>
>> I was indeed wondering about that as well, but ...
>>
>>> I'm going to revert my change.  It didn't cure the oss-fuzz testcase
>>> fails.
>>
>> ... had assumed you already knew it helped. Now that we know it doesn't,
>> maybe we indeed want to look into getting rid of this setjmp/longjmp
>> use.
> 
> I finally managed to reproduce one of the oss-fuzz failures locally,
> by following the recipe at
> https://google.github.io/oss-fuzz/advanced-topics/reproducing/
> 
> It looks to be a bug in clang-15 -fsanitize-coverage.  The following
> code produced for "ins.fwait_prefix >= 0" segfaults at 6666fc due to
> loading a bogus address from 0x78(%rbx).
> 
>   6666f8:       48 8b 43 78             mov    0x78(%rbx),%rax
>   6666fc:       44 0f b6 30             movzbl (%rax),%r14d
>   666700:       bf ff 00 00 00          mov    $0xff,%edi
>   666705:       44 89 f6                mov    %r14d,%esi
>   666708:       e8 d3 9e e7 ff          call   4e05e0 <__sanitizer_cov_trace_const_cmp1>
>   66670d:       45 84 f6                test   %r14b,%r14b
>   666710:       0f 88 10 05 00 00       js     666c26 <print_insn+0x28e6>
> 
> I don't know enough about clang to say what is going on here, but
> presumably the code expects 0x78(%rbx) to contain the address of
> ins.fwait_prefix.  Making ins.fwait_prefix volatile doesn't help.
> So for now I'm just going to ignore this issue (and what I've found so
> far wouldn't make a very good clang bug report).

I hope this will all be taken care of by the first so many patches of
https://sourceware.org/pipermail/binutils/2023-April/126962.html.

Jan