From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 2RIgDlgx1WoDYCwAWB0awg (envelope-from ) for ; Sun, 18 Oct 2026 16:51:36 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ak3umYFy; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 356181E050; Sun, 18 Oct 2026 16:51:36 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,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 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 950901E04E for ; Sun, 18 Oct 2026 16:51:35 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2C1824BA23E5 for ; Sun, 18 Oct 2026 20:51:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2C1824BA23E5 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ak3umYFy Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 6C4CD4BA23C5 for ; Sun, 18 Oct 2026 20:50:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6C4CD4BA23C5 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6C4CD4BA23C5 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1792356647; cv=none; b=UwSTA90HTAUv7HJ7a05QuCWaKWsJ/alAh9PC5+zTh7Mhjqf0Dt6EiKoZc6MvR7r4LcVIXfwKVUTVgNrndZ0smBvm/df4eatePUANmPLtQm8tWhYfrhqEGwC3FmwCiLCWwCLBJJVdi8GsEQXFRzEIWAf1VXak24pwSLolHSVMuQY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1792356647; c=relaxed/simple; bh=6Q6nYn+0HSvcHULBCZ8j1UEHAO/+fPsxEZrJ38B0pfk=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=UykBb/qwcsADmFagZhZwJj0FU5A2eCnQ4cQse1DHWK2FnM5aTYJ4XGcZWDKEs+MoDyDwLBw7arqiwsnJMRSZfM3olrYzFlg7ElLKk37ZSyUdloqHlu2wZOnPPtdcwFut1PfxhHuORPYnEmR4jUNwkUv3J0oPEheZ1mNiFy/df1o= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ak3umYFy DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6C4CD4BA23C5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1792356647; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lwgB8PAxFYcIT10mapzSFxc5ty6U9kOEarEKmUWRfkM=; b=ak3umYFyGGqnYB6Ir0L7m9Im0UKWs5xK9Wqq9/dSTtT3yNDD2yPD2EbdOpqcDo2SKZe6ZD AaxNUsbRe/f9bFv/ysz9FqHtUreuOJ8/Dgqi9u9jQ27gDiaxoEhFiJ3LI+E0nVQxFG2oCe bJ3oE2UxHeVPWvH0EoPTZJmnNDXEIMQ= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-606-kdEYtVjvO4GLmNKg6cqGwA-1; Sun, 18 Oct 2026 20:50:44 +0000 X-MC-Unique: kdEYtVjvO4GLmNKg6cqGwA-1 X-Mimecast-MFC-AGG-ID: kdEYtVjvO4GLmNKg6cqGwA_1792356644 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4a1df727e0cso12369765e9.1 for ; Sun, 18 Oct 2026 13:50:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792356643; x=1792961443; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=lwgB8PAxFYcIT10mapzSFxc5ty6U9kOEarEKmUWRfkM=; b=laedKVv0v23Monfk3MjiCIdD0CQgCy61/v/vKWCjShKN97svK0tloWI4O1MTlntzNE /q58ZI5qmUKvU7W78uThHGU7nTBjFlqwFZbF2+/8gAoJQaRgFMXs/CqTyyb5WB65ceGe 8LqdPfO4077+jdJmUsysgLW/4TUFGgK//Bcq0ukZbaz0TYTHfHQuDE4PwDsDuarT6Okg yFe2/WD02IMINjodQ12vj4PIlmBrFuYB0P4JLrdQaFoHqkO58GJRlkeDoTfFknNufGjS Woc5ucu898fyUwvaOE19k3foRvHW1/5PqyOJd3/ejE4099qOkfbcakLxkQo4J/VhyjK+ xVuA== X-Gm-Message-State: AFq9FYJ/I5v9UfVTe/voPZhZks7uXlwv7iTRapsdyZFuTyvUi/jC2kpb 5nkrYJnCyhaYvxv63EpkdsiaplfYw2OpJdv4DbE2lk6Pr88/0EPEPeXQ5s6+m/RU8kIrFxN1d9U d9/XJb7bn8jN57I8ng5rJme3DLYNEko7gYu7soDAgye1foR2/cLls4sDdj++UjaCG8yobuB4MH6 GSXrFV8NIX+NdmZ9LGyj7lchs84xd9kTBLg307n0U0P0AUfgw= X-Gm-Gg: AYBFou1PKlm2tLe1193ehkik5f/WHIds+C7qBE5dJcIwlb7PPy3yz/a4JNi2/WftH30 FJ3/ymiSfI0J6rJc9QIV2PiKzdUfeb0u6xSqTYjJwxTc9AqaXwTTXbSkHQUjkP4Do4rvy9HtwcP l7sYLLP6tK7c6KJZAjvGj0gtyhlAUwvVv3v0NVGL8qkfDVL8HBOagZZOhEnggS3vKWx2ed5i5ta MD0QbAOYkAEZD+kl7ZHLgFzWyhfGJknShZ11QQmWtC6bS3jH10vQtl2ufvdp/eiH5iWZ4iYlEwa sVhzWXicGNynwMhKLR2RMgsNGY5bmGd8QcLA7iKYn67dyQ/dt/7EcjnRC/e3x9HC+6fo X-Received: by 2002:a05:600c:6994:b0:4a1:e11f:b2ec with SMTP id 5b1f17b1804b1-4a1e11fc152mr71211695e9.3.1792356643516; Sun, 18 Oct 2026 13:50:43 -0700 (PDT) X-Received: by 2002:a05:600c:6994:b0:4a1:e11f:b2ec with SMTP id 5b1f17b1804b1-4a1e11fc152mr71211315e9.3.1792356642959; Sun, 18 Oct 2026 13:50:42 -0700 (PDT) Received: from localhost ([213.31.44.29]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a1d2e93a01sm213886285e9.0.2026.10.18.13.50.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Oct 2026 13:50:42 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCH 2/6] gdb: handle incorrect CU size in .gdb_index Date: Sun, 18 Oct 2026 21:50:31 +0100 Message-Id: <88ff5bde0bbf7a68181ac199bc7facba4fa55432.1792356284.git.aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: qRRkeIXJhCz68W0FGK3DWdNyHcamYLhMoP2W4Q9EgjI_1792356644 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true 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 The CU list within the .gdb_index contains the offset of a CU and the length of the CU. The length field is not needed when parsing the .gdb_index, it is currently only used within GDB to pre-fill the length field of the dwarf2_per_cu object. This pre-filled length is then validated in dwarf2_per_cu::set_length when the real CU header is read from the .debug_info. Unfortunately, this validation is currently done using a gdb_assert, which is the wrong approach. Both the .gdb_index and the CU header are untrusted external input. Either of them (or both of them) might be wrong, and though they should have the same value, this is not guaranteed. I cannot just replace the gdb_assert in dwarf2_per_cu::set_length with a call to complaint, there are other paths where the length is pre-filled from the actual CU header, in this case there should be no possibility of a mismatch, and so gdb_assert is the correct approach. I could add a new member variable to dwarf2_per_cu that tracks if the pre-filled length came from the real CU header or from the .gdb_index, then we could switch on this to either call gdb_assert or complaint. But this seemed excessive when complaints are usually turned off by default. Instead, I propose we just ignore the CU length from the .gdb_index, and pass 0 instead when initially creating the dwarf2_per_cu object. A length of 0 indicates that the CU length is unknown. When GDB reads the actual CU header it will then set the length at this point. The CU length in the .gdb_index is no longer being used, but I am not proposing that we change the .gdb_index format, though we could in theory bump the index version number and remove the CU length, saving a little space. However, changing the index format means more work for downstream tools that read or write .gdb_index sections, so avoiding that churn seems best to me. --- gdb/dwarf2/read-gdb-index.c | 27 ++++++++++++++++--- .../gdb.dwarf2/gdb-index-corrupted.exp | 14 +++++++++- 2 files changed, 37 insertions(+), 4 deletions(-) diff --git a/gdb/dwarf2/read-gdb-index.c b/gdb/dwarf2/read-gdb-index.c index 86512c4ab9c..e0895fb6aa8 100644 --- a/gdb/dwarf2/read-gdb-index.c +++ b/gdb/dwarf2/read-gdb-index.c @@ -573,11 +573,32 @@ create_cus_from_gdb_index_list (dwarf2_per_bfd *per_bfd, sect_offset sect_off = (sect_offset) extract_unsigned_integer (cu_list, 8, BFD_ENDIAN_LITTLE); - ULONGEST length = extract_unsigned_integer (cu_list + 8, 8, BFD_ENDIAN_LITTLE); + /* Each entry in the CU list is a pair of (offset, length), but + we deliberately ignore the length as this information is not + needed. When the real CU contents are read they also contain + a length. The length stored in the .gdb_index and the real + length in the CU header should match, but both the .gdb_index + and the real CU are untrusted input, so could be corrupt, in + which case the lengths might not match. + + If we pre-fill the length here then the dwarf2_per_cu would + need to track that the length came from the .gdb_index so + that later on, when the length is read from the real CU, if + the lengths don't match GDB should use the real length and + warn about the mismatch. + + This feels like a lot of work just for a length field that we + can safely ignore, especially when the complaint mechanism, + through which we would report the length mismatch, is off + by default. Instead, pass 0 as the length to allocate_per_cu + below, this indicates that the length is unknown, and can be + filled in later when the real CU header is read. The length + from the .gdb_index is ignored completely. */ cu_list += 2 * 8; - dwarf2_per_cu_up per_cu = per_bfd->allocate_per_cu (section, sect_off, - length, is_dwz); + /* Pass 0 for the length, see comment above. */ + dwarf2_per_cu_up per_cu + = per_bfd->allocate_per_cu (section, sect_off, 0, is_dwz); units.emplace_back (per_cu.get ()); per_bfd->add_unit (std::move (per_cu)); } diff --git a/gdb/testsuite/gdb.dwarf2/gdb-index-corrupted.exp b/gdb/testsuite/gdb.dwarf2/gdb-index-corrupted.exp index a57b3c26341..356b12f97ce 100644 --- a/gdb/testsuite/gdb.dwarf2/gdb-index-corrupted.exp +++ b/gdb/testsuite/gdb.dwarf2/gdb-index-corrupted.exp @@ -173,6 +173,16 @@ proc run_test { testname } { name _start {{cu_label function global}} name foo {{cu_label function global}} 0xffffff00 } + } elseif { $testname eq "bad-cu-length" } { + # Create an otherwise valid index, but record a bogus length + # for the CU in the index's CU list; one that doesn't match the + # actual length of the CU in .debug_info. GDB should handle + # this gracefully rather than crashing when it later comes to + # expand the CU. + gdb_index {} { + cu cu_label 0x1f + name _start {{cu_label function global}} + } } elseif { $testname eq "valid-index" } { # Generate a well-formed index that includes a valid main # function (valid language, with the name pointing at the @@ -236,7 +246,8 @@ proc run_test { testname } { || $testname eq "main-language" \ || $testname eq "long-cu-vector" \ || $testname eq "name-offset-1" \ - || $testname eq "name-offset-2" } { + || $testname eq "name-offset-2" \ + || $testname eq "bad-cu-length" } { set expect_gdb_index_ignored false set expect_start true set expect_method false @@ -360,6 +371,7 @@ set tests { empty-component \ long-cu-vector \ name-offset-1 \ name-offset-2 \ + bad-cu-length \ valid-index } foreach_with_prefix test $tests { -- 2.25.4