From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id CUzrIFq612rvqzsAWB0awg (envelope-from ) for ; Tue, 20 Oct 2026 15:00:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1792522842; bh=IrW5l42Fqna0//vafGOHLKKVw4ZYJmSKCacCrfc8BHU=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=GtYHC9zEh0uSqIF5F0/43VFCtihp9uH3pd6JoUbL6LwoXQ1UnNNtlqAjYq3lrLPAF SIfyiPQSsyO9dRTHK/p3YbjNLNB+khEQQJUA0DT34E1egUvjbvE966VPrfWdgjzOH1 62bxREk5OP06bAoIuQ+2xoGGC1KjZb3CjCOvygZA= Received: by simark.ca (Postfix, from userid 112) id 65CFA1E04D; Tue, 20 Oct 2026 15:00:42 -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=rYn9rQed; 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 B49051E04D for ; Tue, 20 Oct 2026 15:00:41 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3057D48FEF74 for ; Tue, 20 Oct 2026 19:00:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3057D48FEF74 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=rYn9rQed Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 58A354BA2E3B for ; Tue, 20 Oct 2026 19:00:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 58A354BA2E3B 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 58A354BA2E3B 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=1792522818; cv=none; b=OTbRGfMATJrWcWAzEszrXjqkOIaPP7pF2F4nBGtSFtXma76P+o/OISsZIFlV+3E8tpDIzxYRFUWqmtt02HujzeOPxiBFftKS4PzSLt/XW3snl1NejyX0lhQHHY/M+sKPskXn8//3PnmtaSm+ysH2UrBDYW3/WtJ4ZYXnL7fSVbU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1792522818; c=relaxed/simple; bh=IrW5l42Fqna0//vafGOHLKKVw4ZYJmSKCacCrfc8BHU=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=Vv5heu3bkf6A0lOzRDVD9VdU1qIBymfRhL1lOSwYDYOYCZMTSGiJbiHQT6WaxV1RMooMQStpSXD+UE2uW76vGtXbGrYXUmz5wJ7hqvfV0Od3dXaW0fdWeCGF+ic8Ec3awXpgexx6XE4Ctth7HisEwlkLgj4tMdwr6OwS8FO+FPQ= 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=rYn9rQed DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 58A354BA2E3B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1792522817; bh=IrW5l42Fqna0//vafGOHLKKVw4ZYJmSKCacCrfc8BHU=; h=Date:Subject:To:References:From:In-Reply-To:From; b=rYn9rQedMqYN7X/VYxMv5XNEo2idsIJBEV6STrt1HRusDnKNih7WKhqYny+u4ny5H zIW85NhhQtM5ZKM/ECJzlQsoTvZ8pz6GQJdTuaDWfgbXzUd0DMlQZTAsShLkmpT/Mg B+oCc7b76GXu6ttOtT0b/bvxRTBQTwW1PFDZAQY4= Received: by simark.ca (Postfix) id EC7641E04D; Tue, 20 Oct 2026 15:00:16 -0400 (EDT) Message-ID: <72f2eb0b-315e-42c5-bd18-cb897940b68b@simark.ca> Date: Tue, 20 Oct 2026 15:00:16 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/6] gdb: validate the CU vector offset when loading the .gdb_index To: Andrew Burgess , gdb-patches@sourceware.org References: <17ad2d9bf083c17ea90f2e8ba417b2d0231f66fa.1792356284.git.aburgess@redhat.com> Content-Language: fr From: Simon Marchi In-Reply-To: <17ad2d9bf083c17ea90f2e8ba417b2d0231f66fa.1792356284.git.aburgess@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: > Within the .gdb_index, the symbol table contains indexes that point to > CU vectors within the constant pool. Unfortunately, these indexes are > not validated against the size of the constant pool, so a malformed > .gdb_index can cause GDB to read outside the bounds of the .gdb_index. > > This commit extends the dwarf.exp gdb_index proc to allow for the CU > offset to be overridden, this is then used to add tests that expose > this bug. > > Finally, mapped_gdb_index::build_name_components is updated to sanity > check the CU offset before it is used. If we find an invalid offset > then that symbol will be ignored. > > To improve GDB's ability to catch errors I also added an assert to > offset_view::operator[] that the whole offset_type is within the view. > Without the build_name_components fix this assert will be triggered by > one of the new tests. Again, I skipped the test part for now. > diff --git a/gdb/dwarf2/read-gdb-index.c b/gdb/dwarf2/read-gdb-index.c > index e0895fb6aa8..343ad90847f 100644 > --- a/gdb/dwarf2/read-gdb-index.c > +++ b/gdb/dwarf2/read-gdb-index.c > @@ -102,6 +102,11 @@ class offset_view > /* Extract the INDEXth offset_type from the array. */ > offset_type operator[] (size_t index) const > { > + /* Ensure the whole offset_type is within the underlying bytes. If GDB > + is compiled with libc++ assert then the access of M_BYTES will be Not sure if you meant to say libstdc++ here (maybe clang's libc++ has the same asserts, I don't know). > + checked, but this only guarantees that the first byte is within the > + array_view as it's a gdb_byte view. */ > + gdb_assert (index < size ()); > const gdb_byte *bytes = &m_bytes[index * sizeof (offset_type)]; > return (offset_type) extract_unsigned_integer (bytes, > sizeof (offset_type), > @@ -273,7 +278,22 @@ mapped_gdb_index::build_name_components (dwarf2_per_objfile *per_objfile) > gdb_assert (components.size () > 0); > > std::vector these_entries; > - offset_view vec (constant_pool.slice (symbol_vec_index (idx))); > + > + offset_type vec_index = symbol_vec_index (idx); > + /* The CU vector starts with an offset_type length word. Check that > + VEC_INDEX lands inside CONSTANT_POOL, and that there is at least an > + offset_type worth of bytes beyond this in CONSTANT_POOL to be > + read. */ > + if (vec_index >= constant_pool.size () > + || constant_pool.size () - vec_index < sizeof (offset_type)) Can this be simplified to just: if (vec_index + sizeof (offset_type) > constant_pool.size ()) { // bad } Simon