From patchwork Tue Nov 14 15:42:22 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Willgerodt, Felix" X-Patchwork-Id: 79843 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4F06C3858D37 for ; Tue, 14 Nov 2023 15:42:51 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by sourceware.org (Postfix) with ESMTPS id 53B963858D32 for ; Tue, 14 Nov 2023 15:42:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 53B963858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 53B963858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=134.134.136.100 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699976559; cv=none; b=sbtF9ume5jZEhW7tHO8uxA8irCUlZOjxznYEbex2Mszxf1+m2T0N2VPGZv3f6ZMRCYnmsC5NvGCodHin4etD1SFpvrQ0tHEyliAOgURYwjGCR9TbT7Wu7U7KcW7Atlf3rJ5UAzf4NrEHhbcYD6iXbMQV5e+F11R5F8eXgBTGGGU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699976559; c=relaxed/simple; bh=wqidxpk9aoaJyifNFJA7daqZdmQlIw5Mfs4n12Z1ct4=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=dJ8vQNR0iS9FzQONHu76NrsexagLngciUsvUYyCBAFfbFW4KkwVB6cMdmgWxL59BVUsI1u2+AalL/TSdG3WETpnloWBM5uKwdz4HByBaU7lCFFuYmE8dkQiKDXqkIkah47ESRRGe73/MFIfp4pJwpELhcMfFQpO9Yt/m5PW/H44= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699976558; x=1731512558; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=wqidxpk9aoaJyifNFJA7daqZdmQlIw5Mfs4n12Z1ct4=; b=R+qW/pQN9FqWJvHE08nJeL0haDvX+LIbhqN6GlgItdVED/cJbPJXDKHc MCDdEUYnhuKuYQLhkt+IJKX5ErIg0DQzIG6BUzEAYzZnq9d5A7tIb1yve 13jfdZBsDRrT+Zhe90CQzq2zyfqqmW5tmccMXWFVR4qoOmiawExB3mxUU PAR0aowPX8/reBxgUVo1WTmymi5iWO3PSwQLxsBkxgvoU3bLSZyWiSl2x AEJjS2nlhPdnHxR6ThqElGqW1N1hBI1k83R5tHWsOTrvxET5AWR/hPwVa 3v3RO/lRkavGpOnHwiYd/JmfBXgbyT7El3Bgu5FSsEnICTF6vrVE/k3CN Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10894"; a="457172787" X-IronPort-AV: E=Sophos;i="6.03,302,1694761200"; d="scan'208";a="457172787" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Nov 2023 07:42:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10894"; a="882091865" X-IronPort-AV: E=Sophos;i="6.03,302,1694761200"; d="scan'208";a="882091865" Received: from gkldtt-dev-004.igk.intel.com (HELO localhost) ([10.123.221.202]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Nov 2023 07:42:35 -0800 From: Felix Willgerodt To: gdb-patches@sourceware.org, tom@tromey.com, keiths@redhat.com Subject: [PATCH v2 1/1] gdb: Fix segfault with a big .dynamic section size Date: Tue, 14 Nov 2023 16:42:22 +0100 Message-Id: <20231114154222.2954774-1-felix.willgerodt@intel.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-Spam-Status: No, score=-10.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org 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+patchwork=sourceware.org@sourceware.org Consider a binary with an erroneous size of the .dynamic section: $ readelf a.out ... [24] .dynamic DYNAMIC 0000000000004c20 00003c20 000000fffffffa40 0000000000000010 WA 7 0 8 ... This binary causes a segfault in GDB. GDB is trying to write the .dynamic section into memory allocated on the stack with alloca(). However, the allocation silently fails and the subsequent access to the memory is causing the segfault. (On my node at least.) Stack allocation is a bad idea for something of variable size that GDB has no control over. So I changed the code to heap allocation. In addition, I changed the type of sect_size to the type that bfd actually returns. There should be no user visible change after this. --- gdb/solib.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/gdb/solib.c b/gdb/solib.c index b9fb911a810..d055bea562d 100644 --- a/gdb/solib.c +++ b/gdb/solib.c @@ -1501,7 +1501,8 @@ int gdb_bfd_scan_elf_dyntag (const int desired_dyntag, bfd *abfd, CORE_ADDR *ptr, CORE_ADDR *ptr_addr) { - int arch_size, step, sect_size; + int arch_size, step; + bfd_size_type sect_size; long current_dyntag; CORE_ADDR dyn_ptr, dyn_addr; gdb_byte *bufend, *bufstart, *buf; @@ -1546,7 +1547,8 @@ gdb_bfd_scan_elf_dyntag (const int desired_dyntag, bfd *abfd, CORE_ADDR *ptr, /* Read in .dynamic from the BFD. We will get the actual value from memory later. */ sect_size = bfd_section_size (sect); - buf = bufstart = (gdb_byte *) alloca (sect_size); + gdb::byte_vector buffer (sect_size); + buf = bufstart = buffer.data (); if (!bfd_get_section_contents (abfd, sect, buf, 0, sect_size)) return 0;