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.129.124]) by sourceware.org (Postfix) with ESMTPS id 8D6E73858D38 for ; Tue, 20 Feb 2024 11:58:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8D6E73858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none 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 8D6E73858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708430284; cv=none; b=l4mUJMww7q7mYaJ03QCUMtv+NgsImuD9Ski6pElGv2a3iGQ/+U0EzFBV29p1OmS8y9/zwoMcRa0klwIUEViwFlOA8rbKYTNQSqXdccB8loNqO57vRmr5I3eQFSB56fleceBWZytmT8vcRrLsCDW1VL4hb9hejChu2NIFhiFVO6o= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708430284; c=relaxed/simple; bh=eqr2N/jiC2yjAI0sdUWF31RfWT3kEsmEStAiW5oyWbo=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=RH6UR0KqHFId+ISskZZVunFQaJ4AtOcF1jhqgtj31a9N+EG3DsSBjyMuDX0KXFcaTd8mSlca5j1QtpqLZhncdwiwyihupG4EGqW/zCL1v7GjMLAjilm05DK5talJ29vl/idCsC9mCMPWtDUhAHyy+bA2mcB4ojzpjZmeY4QfTMQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1708430282; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6lo8ZsLixtTjbYZjJP36ZROyD0+It2xKl1ONbK8Fx20=; b=PJB/fn/kq54Jbr2HDnyiZrY7MAi5LaiYRK2YUxhK5zypwpDMJAsFQ0tc9LJSRDj6ds3wqi sCIBrGaAqHMgjGivWWvmYD7pNsH3xZK5JCucVPq3A///D17pHKwfyBcStTBes9T0SSXvY4 qEW3FbYkitn9Yz+f3CK/k5nTPZ3g+58= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-257-bjks8q2CNpCXlYRh4WLP0g-1; Tue, 20 Feb 2024 06:58:00 -0500 X-MC-Unique: bjks8q2CNpCXlYRh4WLP0g-1 Received: by mail-ej1-f69.google.com with SMTP id a640c23a62f3a-a35ef7abe08so302279466b.2 for ; Tue, 20 Feb 2024 03:58:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708430280; x=1709035080; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6lo8ZsLixtTjbYZjJP36ZROyD0+It2xKl1ONbK8Fx20=; b=m+FYVETCKY7Xnw9B3ZkMsN5I/n5i8AKXwYBh5z8yOLr7uk4tfAhDX/OMWFSuA+tMQx zg3plFsK0zlCRtJaCQx8J5kZRxrbZ8iAQpugt5dAAvZ8NcOSX5UxAX0l6uL0a13SZSjj cGT9VTDwegGesAByzHedS0FslA7BDwSp3/OoqdY1LYo8pzh6HdIHXnmjSsWiTGLy0ZD/ wa+bv/SoXuaZng2hfemz4oOfnKjLxPO1PkbKHR6UJrZjdHj4lXXQZ7baOE51o71nLMBh TWnnWoLE2MpjaMoNyqWmTh97lQqtu4+3XHsdXqtdiWRC8CRKdwJhECiU6iwVP3x1Gm4s L5jQ== X-Forwarded-Encrypted: i=1; AJvYcCXNzBCei5h06TMhzUXF7CvRtfQ70LOaiT8hINpwAo6mX7aHy0rAn2JhCQmmUCBkb6xhnlwL2ZhR9S1I0QPhtjMzAbSD+x4rG9s9RA== X-Gm-Message-State: AOJu0YzMQkiTUGbri6gmZ0kuIGiAWAc65KCSRXSmKtvNrjYBv5Uts7tf QxiMw5i8ahi/iJUx9HvJcSE6wuoBRApd3vyJm85u1izpIJk39eGwBFTCogt4eGxzZL44/vVCxe7 XVkBCUTkXj9bEp1nzZEU6zh6wW1FgMJdjMz2xgM+YvdARQ+M+rUGW4I2CH08= X-Received: by 2002:a17:906:1555:b0:a3f:268:a8f8 with SMTP id c21-20020a170906155500b00a3f0268a8f8mr944943ejd.71.1708430279887; Tue, 20 Feb 2024 03:57:59 -0800 (PST) X-Google-Smtp-Source: AGHT+IEdV84DdFp8LZJm6tOtpoS+f8576Ssn4UJRuR5dSntNUGEtKcM2h8v81Z3otHewmMsfE8mmng== X-Received: by 2002:a17:906:1555:b0:a3f:268:a8f8 with SMTP id c21-20020a170906155500b00a3f0268a8f8mr944936ejd.71.1708430279495; Tue, 20 Feb 2024 03:57:59 -0800 (PST) Received: from localhost (185.223.159.143.dyn.plus.net. [143.159.223.185]) by smtp.gmail.com with ESMTPSA id h22-20020a1709063b5600b00a3e274e2e14sm3384455ejf.33.2024.02.20.03.57.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Feb 2024 03:57:59 -0800 (PST) From: Andrew Burgess To: Felix Willgerodt , gdb-patches@sourceware.org Subject: Re: [PATCH 1/1] gdb: Fix segfault in "start" with fuzzed binary In-Reply-To: <20240219151937.743535-1-felix.willgerodt@intel.com> References: <20240219151937.743535-1-felix.willgerodt@intel.com> Date: Tue, 20 Feb 2024 11:57:57 +0000 Message-ID: <87cysr5ovu.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-12.0 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_H2,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 List-Id: Felix Willgerodt writes: > 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. So I think add_to_objfile_sections is where the nullptr is appearing. This is where the obj_section::objfile field is set, but only if the section is allocatable, which after your fuzzing it's not, so the ::objfile field ends up being left as its default value. Even after this patch, it's not obvious that the ::objfile field might be nullptr (looking at struct obj_section in objfiles.h), so maybe it's worth extending the comment there to reflect that. I did wonder if we're wrong to even create a symtab_and_line in this case, we're claiming to have found some debug information for the program image from a particular section which actually wasn't mapped in. But I think fixing that would be a much bigger task, we'd need to chase back all the places where we load debug information which claims to be within a section which is then not going to be allocated. > 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. Not ideal, but I better than a crash :) Thanks, Andrew > (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; > -- > 2.34.1 > > Intel Deutschland GmbH > Registered Address: Am Campeon 10, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928