From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id A25913857352 for ; Fri, 29 Jul 2022 20:57:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A25913857352 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x03.wildebeest.org [172.31.17.133]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 249DC300066F; Fri, 29 Jul 2022 22:57:09 +0200 (CEST) Received: by reform (Postfix, from userid 1000) id A74A02E81A40; Fri, 29 Jul 2022 22:57:09 +0200 (CEST) Date: Fri, 29 Jul 2022 22:57:09 +0200 From: Mark Wielaard To: Ben Woodard Cc: Ben Woodard via Libabigail Subject: Re: libabigail 2.1 trunk testing where are we? Message-ID: References: <5BA0C098-9E22-4604-8C13-1D0624B2489F@redhat.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="c+j5vyG+mz8RpCUz" Content-Disposition: inline In-Reply-To: <5BA0C098-9E22-4604-8C13-1D0624B2489F@redhat.com> X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, GIT_PATCH_0, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, 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: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2022 20:57:13 -0000 --c+j5vyG+mz8RpCUz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jul 29, 2022 at 11:28:18AM -0700, Ben Woodard via Libabigail wrote: > 1 crash due to incorrect ELF in that shows up in a small number of > packages https://sourceware.org/bugzilla/show_bug.cgi?id=29346 I have a patch that should work around that on: https://code.wildebeest.org/git/user/mjw/libabigail/commit/?h=pr29346 Also attached. Maybe someone with commit access could push it to a users try branch for testing? Thanks, Mark --c+j5vyG+mz8RpCUz Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-Handle-zero-sh_entsize-in-get_soname_of_elf_file.patch" >From 05c53fcbdbccd8b08dfabd22caa9c7b4625596e8 Mon Sep 17 00:00:00 2001 From: Mark Wielaard Date: Wed, 20 Jul 2022 01:01:14 +0200 Subject: [PATCH] Handle zero sh_entsize in get_soname_of_elf_file Apparently guile produced ELF files don't set sh_entsize for the dynamic section. Which would cause a divide by zero. Luckily we do know how big an dynamic entry should be. So use gelf_fsize for ELF_T_DYN if sh_entsize is zero. * src/abg-dwarf-reader.cc (get_soname_of_elf_file): Make sure entsize is non-zero before use. https://sourceware.org/bugzilla/show_bug.cgi?id=29346 Signed-off-by: Mark Wielaard --- src/abg-dwarf-reader.cc | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/abg-dwarf-reader.cc b/src/abg-dwarf-reader.cc index e5159c89..288a56b8 100644 --- a/src/abg-dwarf-reader.cc +++ b/src/abg-dwarf-reader.cc @@ -16629,8 +16629,11 @@ get_soname_of_elf_file(const string& path, string &soname) Elf_Scn* scn = gelf_offscn (elf, phdr->p_offset); GElf_Shdr shdr_mem; GElf_Shdr* shdr = gelf_getshdr (scn, &shdr_mem); + size_t entsize = (shdr != NULL && shdr->sh_entsize != 0 + ? shdr->sh_entsize + : gelf_fsize (elf, ELF_T_DYN, 1, EV_CURRENT)); int maxcnt = (shdr != NULL - ? shdr->sh_size / shdr->sh_entsize : INT_MAX); + ? shdr->sh_size / entsize : INT_MAX); ABG_ASSERT (shdr == NULL || shdr->sh_type == SHT_DYNAMIC); Elf_Data* data = elf_getdata (scn, NULL); if (data == NULL) -- 2.30.2 --c+j5vyG+mz8RpCUz--