From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 63F5D3858CDA for ; Thu, 14 Sep 2023 15:49:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 63F5D3858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694706574; 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; bh=Ezk8NfQD80koWSPGlNTCbq7JDvx/0EyJY05ePfKXnWI=; b=HcULdb7Nj+mH0+1AfbAPdFQY+zX/839NM8g6X8FWKm0NIJqGAdsTOuzEIczuaqc8KgGahL ohjiOOOxEgmKgQlP7bIoYAH6I7mgppuNIgouEczdF64x4wXS5WiYoVXPV9XNhfPqhLlevS BZKRgcbptiVFUVBJUI7BoeE1spNplZE= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-448-8jNZFGh2P7irAsdacx3Vhg-1; Thu, 14 Sep 2023 11:48:26 -0400 X-MC-Unique: 8jNZFGh2P7irAsdacx3Vhg-1 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-31f87a56b46so681408f8f.2 for ; Thu, 14 Sep 2023 08:48:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694706494; x=1695311294; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ezk8NfQD80koWSPGlNTCbq7JDvx/0EyJY05ePfKXnWI=; b=dePCZvUG9jfuRr6Ga39z+LcT2M4Fyzm8rMnVE+tOfToihmGKX/c5Cftd8f84bKTe30 fSZO3FcuY0mStI2Hc2GW1z38PLS9P4r+5A7ZFMtiTTS2OgGxaHIfOg6gO4i56SEq7Fix 7ELoyGkZ/RsbE63n4XmlyxRrzEx2zLiJHO1SC/RzNqn2BA1SS1ZMGdtWmWr3l5Bv5bqg 47sHNFgbC0NnVERQSsefsLgbEh0CAFeWZfy3N15DLGpS/hd2TxH5WZyJ71SukWnvf2oO T4FGMVXZmegTj7hTNCffJcy+kPTA78Jy/0/l17I3S4K+Y+RlGQCYc0pLw5Y5+KY/VE0u vRJw== X-Gm-Message-State: AOJu0Yy5YV1IheF5zUyxe6anlmCEmjRY7xqVleTxMt/g5LybIhN8pg8n cQ6RFhiZmH5XP0cEAliIm43yZ1fbKnIfuKgjDC08l4jnCTTsjdQtO+gMvo5Q3xDB0ERXzIQQ/pk sZWoBmAmLmcB+UXjuXlOgJVYclKKrRauEjSJU92T5k0TSkiAmqyge7W9wJHl6JVHwr7aMRqlv2c YhSvZngw== X-Received: by 2002:adf:e641:0:b0:31f:b120:143 with SMTP id b1-20020adfe641000000b0031fb1200143mr5508269wrn.59.1694706494365; Thu, 14 Sep 2023 08:48:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHLyu5yNIHBmosLamcRlSakuC9edz47R2eHz7rGT1f4qLsttjkpvOVwmT43lxbl8G5uScbRLA== X-Received: by 2002:adf:e641:0:b0:31f:b120:143 with SMTP id b1-20020adfe641000000b0031fb1200143mr5508250wrn.59.1694706494026; Thu, 14 Sep 2023 08:48:14 -0700 (PDT) Received: from localhost (197.126.90.146.dyn.plus.net. [146.90.126.197]) by smtp.gmail.com with ESMTPSA id d6-20020adfef86000000b0031f82743e25sm2090858wro.67.2023.09.14.08.48.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Sep 2023 08:48:13 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Tom Tromey , Andrew Burgess Subject: [PATCH] gdb: fix buffer overflow in DWARF reader Date: Thu, 14 Sep 2023 16:48:09 +0100 Message-Id: <281fdfc6ef3997cfab17d2379b51b208c0e00070.1694706424.git.aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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 List-Id: In this commit: commit 48ac197b0c209ccf1f2de9704eb6cdf7c5c73a8e Date: Fri Nov 19 10:12:44 2021 -0700 Handle multiple addresses in call_site_target a buffer overflow bug was introduced when the following code was added: CORE_ADDR *saved = XOBNEWVAR (&objfile->objfile_obstack, CORE_ADDR, addresses.size ()); std::copy (addresses.begin (), addresses.end (), saved); The definition of XOBNEWVAR is (from libiberty.h): #define XOBNEWVAR(O, T, S) ((T *) obstack_alloc ((O), (S))) So 'saved' is going to point to addresses.size () bytes of memory, however, the std::copy will write addresses.size () number of CORE_ADDR sized entries to the address pointed to by 'saved', this is going to result in memory corruption. The mistake is that we should have used XOBNEWVEC, which allocates a vector of entries, the definition of XOBNEWVEC is: #define XOBNEWVEC(O, T, N) \ ((T *) obstack_alloc ((O), sizeof (T) * (N))) Which means we will have set aside enough space to create a copy of the contents of the addresses vector. I'm not sure how to create a test for this problem, this issue cropped up when debugging a particular i686 built binary, which just happened to trigger a glibc assertion (likely due to random memory corruption), debugging the same binary built for x86-64 appeared to work just fine. Using valgrind on the failing GDB binary pointed straight to the cause of the problem, and with this patch in place there are no longer valgrind errors in this area. If anyone has ideas for a test I'm happy to work on something. --- gdb/dwarf2/read.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 98bedbc5d49..0f4d99109fb 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -10548,7 +10548,7 @@ read_call_site_scope (struct die_info *die, struct dwarf2_cu *cu) std::vector addresses; dwarf2_ranges_read_low_addrs (ranges_offset, target_cu, target_die->tag, addresses); - unrelocated_addr *saved = XOBNEWVAR (&objfile->objfile_obstack, + unrelocated_addr *saved = XOBNEWVEC (&objfile->objfile_obstack, unrelocated_addr, addresses.size ()); std::copy (addresses.begin (), addresses.end (), saved); base-commit: d7680f13df105aa8fa0edbdf8efae31a5411f579 -- 2.25.4