From patchwork Mon Feb 19 15:19:37 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Willgerodt, Felix" X-Patchwork-Id: 85994 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 D6E633858407 for ; Mon, 19 Feb 2024 15:20:20 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by sourceware.org (Postfix) with ESMTPS id 59A8A385840D for ; Mon, 19 Feb 2024 15:19:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 59A8A385840D 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 59A8A385840D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708355989; cv=none; b=g5pSqnOQoiH/yD2E2crs85g0Mt+BLBB07dJHa2TBqHiFu+fsYkeW38vDNXa3agzUrpnL8CSKHJXwBdVcWJlfFGJBxMkIg7C6WZWQ5xvoOkSKakxruoF4ZE1bhoYQNNBGVB/Y0GRQzIoaFM+lTGfRJ3YsboAqm8j3lAy/fqo9ARo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708355989; c=relaxed/simple; bh=fUxTBKAz6mnR9liTIMM7mJ9UiQA4tozjBhpy6nbDB9E=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=sl2hfK1K+JhvazpmLy86gEthAQ1hYm1m7pbuqb6LuPRkfD/j/F40NRVHLn8Q52iIqNLzkXT9Wb9XwKZnXPOwC6UBW1WqrqhFBKfXUU7ngE9pfMjeVeXJdCintTeTf8FtU16djZbEYWBpT5WqpguZal7atA+Jj3szD34maXyhI64= 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=1708355987; x=1739891987; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=fUxTBKAz6mnR9liTIMM7mJ9UiQA4tozjBhpy6nbDB9E=; b=Zgt4zPjBqS69LfIpUaDARBbEXmq6YDpzgfuhaj2ByK8E4AM+M7xOu3L4 pJdB5hixvruBd3k30RPlTyxnCKFonk8axhQV+fmgd/k9Y36X4POxt3rXy ZebS66z8RDwzqBM6YJTaPEMenIdqp/DjubKgpWgqq7/x4mdJWff1D7uHs qrjy4oiy46M3DZIxab7PDGXC38XFQbMiERrWnxDhDNBwA5Qsex4Y0ebCh NDDGuAN7C3triQ7hIfCONGncGnjZo0zU1DstWactZj+Fg1LbsF6gaYINz cadF44OjioBwrOlEkUZJ8PhHD4/t/AOshZAjwhYiNl13BVN1GfC9DbYzW Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10989"; a="13147454" X-IronPort-AV: E=Sophos;i="6.06,170,1705392000"; d="scan'208";a="13147454" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2024 07:19:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,170,1705392000"; d="scan'208";a="35547315" Received: from gkldtt-dev-004.igk.intel.com (HELO localhost) ([10.123.221.202]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2024 07:19:44 -0800 From: Felix Willgerodt To: gdb-patches@sourceware.org Subject: [PATCH 1/1] gdb: Fix segfault in "start" with fuzzed binary Date: Mon, 19 Feb 2024 16:19:37 +0100 Message-Id: <20240219151937.743535-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 I found this while playing around with fuzzing. Though I did fuzz with "-ex start", so this isn't a security issue. But any comments welcome. What I observed is this segfault: ~~~ Thread 1 "gdb-up" received signal SIGSEGV, Segmentation fault. 0x0000555555d8883a in objfile::arch (this=0x0) at /user/sources/gdb/gdb/objfiles.h:509 509 return per_bfd->gdbarch; (gdb) bt 5 filter_=..., cond_string_=..., extra_string_=..., disposition_=disp_del, thread_=-1, simd_lane_num_=-1, task_=-1, inferior_=1, ignore_count_=0, from_tty=0, enabled_=1, flags=0, display_canonical_=0) at /user/sources/gdb/gdb/breakpoint.c:8960 (More stack frames follow...) (gdb) frame 1 7645 return sal.section->objfile->arch (); (gdb) p sal.section $1 = (obj_section *) 0x555558828bf8 (gdb) p *sal.section $2 = {the_bfd_section = 0x0, objfile = 0x0, ovly_mapped = 0} ~~~ The parsed binary has a weird .text section header: [14] .text LOUSER+0x6c0000 0000000000001040 00001040 00000000000000f9 0000000000000000 WX 0 0 16 It is marked as writeable (I think) and the type is also different. For reference here is the one from the normal binary that I started fuzzing with: [14] .text PROGBITS 0000000000001040 00001040 00000000000000f9 0000000000000000 AX 0 0 16 I couldn't find where GDB actually parses this. Nor could I figure out why the section has a nullptr as objfile. But after this patch, the segfault is gone and the output seems reasonable for a broken binary: Temporary breakpoint 1 at 0x1040: file main.c, line 1. Starting program: a.out /bin/bash: line 1: a.out: Permission denied /bin/bash: line 1: exec: a.out: cannot execute: Permission denied During startup program exited with code 126. (gdb) In addition this changes the function to use explicit comparisons. --- gdb/breakpoint.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c index 5f05657a8b3..0313b920ca6 100644 --- a/gdb/breakpoint.c +++ b/gdb/breakpoint.c @@ -7641,9 +7641,9 @@ set_breakpoint_location_function (struct bp_location *loc) struct gdbarch * get_sal_arch (struct symtab_and_line sal) { - if (sal.section) + if (sal.section != nullptr && sal.section->objfile != nullptr) return sal.section->objfile->arch (); - if (sal.symtab) + if (sal.symtab != nullptr) return sal.symtab->compunit ()->objfile ()->arch (); return NULL;