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 63D113858D32 for ; Tue, 26 Jul 2022 15:28:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 63D113858D32 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 tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 2B81E300B33A; Tue, 26 Jul 2022 17:28:13 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id CD1E4413CBBB; Tue, 26 Jul 2022 17:28:11 +0200 (CEST) Message-ID: Subject: Re: runtime validation of DT_SYMTAB lookups - why is there no DT_SYMSZ? From: Mark Wielaard To: Milian Wolff , elfutils-devel@sourceware.org Date: Tue, 26 Jul 2022 17:28:11 +0200 In-Reply-To: <2825590.45ddzSUfD6@milian-workstation> References: <2825590.45ddzSUfD6@milian-workstation> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2022 15:28:17 -0000 Hi Milian, On Mon, 2022-07-11 at 18:40 +0200, Milian Wolff wrote: > in heaptrack I have code to runtime attach to a program and then > rewrite the=20 > various rel / rela / jmprel tables to intercept calls to malloc & friends= . >=20 > This works, but now I have received a crash report for what seems to > be an=20 > invalid DSO file: The jmprel table contains an invalid entry which > points to=20 > an out-of-bounds symbol, leading to a crash when we try to look at > the=20 > symbol's name. >=20 > I would like to protect against this crash by detecting the invalid > symbols.=20 > But to do that, I would need to know the size of the symbol table, > which is=20 > much harder than I would have hoped: >=20 > We have: >=20 > ``` > #define DT_SYMTAB 6 /* Address of symbol table */ > #define DT_SYMENT 11 /* Size of one symbol table > entry */ > ``` >=20 > But there is no `DT_SYMSZ` or similar, which we would need to > validate symbol=20 > indices. Am I overlooking something or is that really missing? Does > anyone=20 > know why? The other tables have that, e.g.: >=20 > ``` > #define DT_PLTRELSZ 2 /* Size in bytes of PLT relocs */ > #define DT_RELASZ 8 /* Total size of Rela relocs */ > #define DT_STRSZ 10 /* Size of string table */ > #define DT_RELSZ 18 /* Total size of Rel relocs > */ > ``` >=20 > Why is this missing for the symtab? > > The only viable alternative seems to be to mmap the file completely > to access=20 > the Elf header and then iterate over the Elf sections to query the > size of the=20 > SHT_DYNSYM section. This is pretty complicated, and costly. Does > anyone have a=20 > better solution that would allow me to validate symbol indices? I don't know why it is missing, but it is indeed a tricky issue. You really want to know the number of elements (or the size) of the symbol table, but it takes a little gymnastics to get that. Di Chen recently (or actually not that recently, I just still haven't reviewed, sorry!) posted a patch for=20 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28873 to print out the symbols from the dynamic segment=20 https://sourceware.org/pipermail/elfutils-devel/2022q2/005086.html > PS: eu-elflint reports this for the broken DSOs e.g.: > ``` > $ eu-elflint libQt5Qml.so.5.12 > section [ 3] '.dynsym': symbol 1272: st_value out of bounds > section [ 3] '.dynsym': symbol 3684: st_value out of bounds > section [29] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol size 0 does not > match=20 > .got section size 18340 > section [29] '.symtab': _DYNAMIC symbol size 0 does not match dynamic > segment=20 > size 336 > section [29] '.symtab': symbol 25720: st_value out of bounds > section [29] '.symtab': symbol 27227: st_value out of bounds > ``` >=20 > Does anyone know how this can happen? Is this a bug in the toolchain? Try with eu-elflint --gnu which suppresses some known issues. Also could you show those symbol values (1272, 3684, 25720, 27227) they might have a special type, so their st_value isn't really an address? Cheers, Mark