From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id XsijGMG/12qWyDsAWB0awg (envelope-from ) for ; Tue, 20 Oct 2026 15:23:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1792524225; bh=Ec0FekUHt2IK+r4mCthYT7QknZ/eMu1RPdqHf7aZ30A=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=lXHMcQTHOhTplUEUqTqzRWDKRMuEZ169PHmVjiZwV3c1SDEuZrFSWoiQFEVzeCBmC 0JdpA3z4HwPi1Jtw8sltYcZAn6hlg2Y4eIgwcRdJTq4k1DlU1upy1tw+WjlZc6bvFd Bdde0a34bKn8VHKQyBT44mRJvx3+effugrGcb6Z8= Received: by simark.ca (Postfix, from userid 112) id 4B6261E04D; Tue, 20 Oct 2026 15:23:45 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=RFsy2TsA; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A15A91E04D for ; Tue, 20 Oct 2026 15:23:44 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 280DF4B920DA for ; Tue, 20 Oct 2026 19:23:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 280DF4B920DA Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=RFsy2TsA Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 086954B99F55 for ; Tue, 20 Oct 2026 19:23:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 086954B99F55 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 086954B99F55 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1792524200; cv=none; b=Q6hngtGGrBylVaUgJaSbFkaqItZmpM6rlrAf2XdNN4UZVaAcGCOsERK5hIE0p32eXPid0nsatpJVR/AvRY1d94cQy8KxeKBe01szHw8V3SPgH5aBX7y3QrcqEUjW6rJj6XE/TUSVhPpcr20NeXshpQZbs+Ufr5djie64pKiLhy8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1792524200; c=relaxed/simple; bh=Ec0FekUHt2IK+r4mCthYT7QknZ/eMu1RPdqHf7aZ30A=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=tXXJfjcTXHvBquwNpCzQm+mZoevVWIOV9CsFr9xYoRu6392x9FhaYW+YTq0/OTAGRma1tJ71paX3YDqSNM6Zp2A5wCYE4PxzxL7SrHACjudXJpmQ0JOslOjr2AnZLGlluUvzTw8p+ZsQi1uNnPLqDvuxbo3zdWajgqiNjhXj6SQ= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=RFsy2TsA DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 086954B99F55 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1792524198; bh=Ec0FekUHt2IK+r4mCthYT7QknZ/eMu1RPdqHf7aZ30A=; h=Date:Subject:To:References:From:In-Reply-To:From; b=RFsy2TsAGMF2ZFStRpjfHVB384pxgKqKlqTUHz/UIdXIUGXNc3+rM/doXh1MhDvVA qU1vkPk3Z4VK1bgEPyGX6FWZPTzwK261FTsARTaiWQRdqjmyp3DHOislSIAd06IlIr s9iQD4sdMnXwoc72tKPXmv59Tanp+YGnTbSRITS0= Received: by simark.ca (Postfix) id 40A251E04D; Tue, 20 Oct 2026 15:23:18 -0400 (EDT) Message-ID: <405910c8-c69b-47c3-ad5b-ba7e8200b492@simark.ca> Date: Tue, 20 Oct 2026 15:23:17 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 5/6] gdb: handle corrupted .gdb_index header offsets To: Andrew Burgess , gdb-patches@sourceware.org References: Content-Language: fr From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 10/18/26 4:50 PM, Andrew Burgess wrote: > The .gdb_index section has a header. The header is a list of offsets > into the .gdb_index section. Currently GDB has basically no error > checking of these offsets, the offsets can point outside the > .gdb_index section and GDB will usually try to do something bad as a > result. > > Most often a bad offset will result in GDB trying to allocate a huge > amount of memory. Indeed, I don't recommend running these new tests > on an unpatched GDB; I managed to bring down my machine due to > excessive memory allocation. > > I've added a mechanism to the gdb_index proc (in lib/dwarf.exp) to > allow the various .gdb_index header offsets to be overridden. Then I > made use of this in gdb.dwarf2/gdb-index-corrupted.exp to override > each offset in turn. > > I also added a new test gdb.dwarf2/gdb-index-tiny-header.exp which > tests with a .gdb_index sized between 0 and 28 bytes (inclusive). > This covers indexes that are too small to even hold a valid version > number field, and indexes upto the size of the full header block. All > of these indexes are too small to hold useful data so GDB should > reject them all (without crashing). > > The changes in gdb/dwarf2/read-gdb-index.c are fairly straightforward; > check the .gdb_index is big enough for the version field, then use the > version field to check that we have all of the offsets, and that the > offsets point within the .gdb_index section. > > Also, as the data areas that the .gdb_index header offsets point to > are arranged in offset order, I also check that offsets are always > equal or increasing in value. Claude suggested this as follow-up: - Pre-existing, non-blocking (follow-up): the CU list size isn't checked to be a multiple of 16, nor the TU list a multiple of 24. create_cus_from_gdb_index_list (i += 2 over size/8 elements) and the TU loop (read-gdb-index.c:721, i += 3) then read up to 16 bytes past the end of the block. For the dwz index nothing has to follow the CU list, so the read can go past the end of the section. This patch is the natural place to add that check. I think that makes sense, it could be a follow-up. We could decide to reject the index entirely, or just ignore the incomplete entries at the end. > @@ -513,6 +529,49 @@ read_gdb_index_from_buffer (const char *filename, > > map->version = version; > > + /* The .gdb_index header is a version number followed by a series of > + offsets into the .gdb_index section. Each header offset points to a > + data block, and the offset order, and the data block order are the > + same. This means that each offset must be greater than, or equal to > + the previous. The first offset should point to the first byte after > + the .gdb_index header. None of the header offsets should point outside > + of the .gdb_index section. > + > + If any of these requirements are not met then GDB can end either > + crashing by accessing invalid memory, or trying to allocate a huge Missing "up", "can end up either crashing". Simon