From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-sender-0.a4lg.com (mail-sender-0.a4lg.com [IPv6:2401:2500:203:30b:4000:6bfe:4757:0]) by sourceware.org (Postfix) with ESMTPS id 124143858D1E; Tue, 4 Oct 2022 10:14:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 124143858D1E Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail-sender-0.a4lg.com (Postfix) with ESMTPSA id 19C38300089; Tue, 4 Oct 2022 10:13:59 +0000 (UTC) Message-ID: Date: Tue, 4 Oct 2022 19:13:57 +0900 Mime-Version: 1.0 Subject: Re: [PATCH v2 1/2] RISC-V: Fix buffer overflow on print_insn_riscv Content-Language: en-US To: Jan Beulich , Binutils , gdb-patches@sourceware.org References: <5ca714bd-24d6-54c6-bce1-08cb3b77a47a@suse.com> From: Tsukasa OI In-Reply-To: <5ca714bd-24d6-54c6-bce1-08cb3b77a47a@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2022 10:14:03 -0000 On 2022/10/04 18:58, Jan Beulich wrote: > On 04.10.2022 11:45, Tsukasa OI wrote: >> --- a/include/opcode/riscv.h >> +++ b/include/opcode/riscv.h >> @@ -55,6 +55,8 @@ static const char * const riscv_pred_succ[16] = >> "i", "iw", "ir", "irw", "io", "iow", "ior", "iorw" >> }; >> >> +#define RISCV_MAX_INSN_LEN 22 /* max 176-bit encoding. */ > > To be honest this still doesn't look sufficient to me: There's still > no connection between this constant and riscv_insn_length(). Yet both > want changing at the same time when it comes to insn length aspects. > As said in reply to v1 - comments may be one way of dealing with this. > We don't have BUILD_BUG_ON() or alike (and even if we had it wouldn't > be usable in a portable way), so an actual build time check might not > be feasible. A runtime check also doesn't look realistic, as > > gas_assert (riscv_insn_length(~0) == RISCV_MAX_INSN_LEN); > > wouldn't be correct, and I'm unconvinced of using other than the most > simple ~0 as an argument here. > > Jan > I have to agree that the constant with no direct connection with riscv_insn_length is not good but I don't come up with better solution than this (with given constraints). In any case, keeping this stack buffer overflow is definitely a bad idea and we have to do something to deal with it in a days. Tsukasa