[Bug gas/30857] Use of uninitialized memory

[jacob at jacob dot remcomp.fr]

https://sourceware.org/bugzilla/show_bug.cgi?id=30857

--- Comment #1 from jacob at jacob dot remcomp.fr ---
Wow, actually, bugzilla goes into this group!

What is the point then of telling me to « go to bugzilla » ???

I just do not understand this group really.

Jacob


> Le 15 sept. 2023 à 12:48, jacob at jacob dot remcomp.fr 
> <sourceware-bugzilla@sourceware.org> a écrit :
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=30857
> 
>            Bug ID: 30857
>           Summary: Use of uninitialized memory
>           Product: binutils
>           Version: 2.15
>            Status: UNCONFIRMED
>          Severity: normal
>          Priority: P2
>         Component: gas
>          Assignee: unassigned at sourceware dot org
>          Reporter: jacob at jacob dot remcomp.fr
>  Target Milestone: ---
> 
> FUNCTION: riscv_ip_hardcode
> FILE: gas/config/tc-riscv.c LINE: 3682
> Problem: Usage of uninitialized memory.
> Variable: Local variable of type "riscv_opcode *" insn.
> 
> Description:
> This variable is initialized with a call to XNEW(struct riscv_opcode);
> 3721:   insn = XNEW(struct riscv_opcode);
> All fields of this structure are garbage since we called malloc.
> The next line initializes ONE of those fields:
> 3722:   insn->match = values[num - 1];
> Then, a call to "create_insn" is done:
>        create_insn(ip,insn);
> The function "create_insn" initializes its left argument with the values of
> its right argument. In this case however, it will "initialize" its left
> argument with a structure that contains mostly garbage since only ONE field
> has been really initialized!
> 
> There is only ONE place where riscv_ip_hardcode is called: in function
> s_riscv_insn. After the call, s_riscv_insn assumes that insn has been
> correctly initialized and makes:
> 4868:   gas_assert(insn.insn_mo->pinfo != INSN_MACRO);
> without realizing that insn.insn_mo->pinfo is a garbage value.
> 
> Analysis: Garbage values are unlike to be 0xffffffff, the value of 
> INSN_MACRO, so in most cases this inequality will be true, and the code
> continues to run as if nothing would be wrong. In some cases the code
> will fail with an "assertion failed" message. Since this bug is not
> reproducible... any bug reports will be discarded.
> 
> HOW TO FIX:
> 1) Intead of calling XNEW call XCNEW that calls calloc instead of malloc.
>  This will ensure that the inequality will fail.
> 2) Initialize all values to sensible values. This is much more difficult and
>  involves much more effort, probably for nothing since those values aren't
>  used.
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.