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 A7FA03858D20 for ; Sun, 7 Apr 2024 13:57:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A7FA03858D20 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 A7FA03858D20 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=1712498264; cv=none; b=egHwM7pIHihBu4MjHSCkxbTx5ZZXGI9VBbOSRumvEJYXNSjiOAzhaPJ4SZnNbB7Qf0a6X4Tjh4bG6dmFWzPMHmDIT6sviTYitoXfA9YKjfjrMLtllLva9CC6gWf3yiIcQT2OeiMjYn08Wi4HnnV+ySp5g0zk30wTtQ9eELB40D4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712498264; c=relaxed/simple; bh=XLhWC83dZu2Bif/yF3wAIz5ADMH/bXC8ayKWRcO9Kbs=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=A6JPGhqYTyk5Ps/sicvFpotAHFhzfnrM8DoyjytFes+NjKf9rbuyBW2k199ASO9xlqZz9L7bM81Vj951AHQNeoQRSIzZJD/SeiShIUMXEJ6Cl87UKVa3TJwrej9vWgh29inC45cazqykmH/W6UTQrzpBkFTVZhdt9UwFkhfxqoM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712498262; 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=yXd58CkQr1Sg1geXNdgv9eZKP0dxoFj7yx0dU2ALIo4=; b=FjCLBb6Z1kD1eno7JltayNM09MlIre9efRL/6NunmPDeBjpw67CZnTwC+lz9IV2XuCvS2/ vwgXzCLYdkk5hBXtLeJPgRNRUZAuWLYan7vkIn/os1HxHR4A9E+Uahi8E1c3h3l71jzo8a mkHDKRUOFwE/BBYmiuEIGClcB1nXYSI= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-133-UEBqkRb4MOy0hSUrBmc_Rg-1; Sun, 07 Apr 2024 09:57:40 -0400 X-MC-Unique: UEBqkRb4MOy0hSUrBmc_Rg-1 Received: by mail-ed1-f71.google.com with SMTP id 4fb4d7f45d1cf-56e3f8cc8f4so703098a12.1 for ; Sun, 07 Apr 2024 06:57:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712498259; x=1713103059; 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=yXd58CkQr1Sg1geXNdgv9eZKP0dxoFj7yx0dU2ALIo4=; b=SAP+T1lW66aQa6EPE5EF4k+rmA0EuGCM373RVLNBgybpgOFz8icAYHbbkNy2QJ/5g9 aznpKaTUGzFJUKQp8Gdv69HK3M69dakE6i7naNW3WHgLmgP5+NokoXIlXEhd6b4Z2Y/J NMUdJkDnC/x6R40VNS3D1KjxkUyH20+9wzMDRtNwCFfjfBZ3jTmK5aGxrCbn2Cjg3Afe G0RRbfzGzzCy3M/D0wbKNu5vy5LtPR6+UY6fktfHb2P2YchxalE2DLIXrf2xjOjYUmN9 m7l0V6l9PoIo1/fS+kP14vt68WicXAwnDqa7TESCYVx6bty7HeJgsMVkYZsY/hDr8x8L aRJA== X-Forwarded-Encrypted: i=1; AJvYcCUpUvYvrg5yEISFK8FTiAUtUQImOnGUt13TLgFB7Y9BfypFS2/OyLdbUWuZZLfCbJ8uxYTFFXJIhqlT8aVt70Td9NtF2leQhZC11w== X-Gm-Message-State: AOJu0Yx9MXsp5N3qY7B/kB4RKaM+PCo+WOI4FkLkr7NWF3ot6RTc7vKg wee4nJJ058ZBRLt4nYAXP5Xtex2RIgR7c9uv575MU1o6yaG69RDrcp6MInk0o4DkcLkgs5BtKTV byssMbXhgMEI9P11RfgUNq7MDxd0N8gNYrSsizCwgHmp1srDoHxVV8L0tCdA= X-Received: by 2002:a50:cd13:0:b0:56b:b6a2:2048 with SMTP id z19-20020a50cd13000000b0056bb6a22048mr5086127edi.24.1712498259573; Sun, 07 Apr 2024 06:57:39 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFqLTxH8KGEYQbZxLg3TM3px1eDfc8zw4Pxr4ERtYkK2R6f5j9HzD9lcSqrTkr9vAOSRh8g5g== X-Received: by 2002:a50:cd13:0:b0:56b:b6a2:2048 with SMTP id z19-20020a50cd13000000b0056bb6a22048mr5086117edi.24.1712498259009; Sun, 07 Apr 2024 06:57:39 -0700 (PDT) Received: from localhost (185.223.159.143.dyn.plus.net. [143.159.223.185]) by smtp.gmail.com with ESMTPSA id 10-20020a0564021f4a00b0056e5af5477fsm292061edz.54.2024.04.07.06.57.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Apr 2024 06:57:38 -0700 (PDT) From: Andrew Burgess To: "Willgerodt, Felix" , "gdb-patches@sourceware.org" Subject: RE: [PATCH 1/1] gdb: Fix segfault in "start" with fuzzed binary In-Reply-To: References: <20240219151937.743535-1-felix.willgerodt@intel.com> <87cysr5ovu.fsf@redhat.com> Date: Sun, 07 Apr 2024 14:57:37 +0100 Message-ID: <87a5m52s32.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=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,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: "Willgerodt, Felix" writes: >> -----Original Message----- >> From: Andrew Burgess >> Sent: Dienstag, 20. Februar 2024 12:58 >> To: Willgerodt, Felix ; gdb-patches@sourceware.org >> Subject: Re: [PATCH 1/1] gdb: Fix segfault in "start" with fuzzed binary >> >> 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. >> > > Hi Andrew, > > thanks for even looking at this. Since it isn't a security issue I was wondering > if we even care much about this. I don't really know if we would ever see > such an ELF file and care about not crashing with it after a start. > But the patch I wrote did seem harmless enough to post as a proposal. > > I did check add_to_objfile_sections() and I don't see the nullptr being added there. > So it must be somewhere else. (Wouldn't it even segfault there if objfile > would be nullptr?) When you say you don't see the nullptr being added, what do you mean exactly? As far as I can tell, this is where obj_section::objfile is set from nullptr to non-nullptr, but that only happens for allocatable sections. In your case you specifically said the fuzzer made the section non-allocatable, so that assignment of obj_section::objfile will not happen, and obj_section::objfile will be left with its default (nullptr) value. At least, that's my thinking. I haven't actually tested this, so possibly I'm not understanding something! Thanks, Andrew