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-bugzi...@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.