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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTPS id 2BD233858D28 for ; Fri, 5 Nov 2021 14:35:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2BD233858D28 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-593-yrL8_tHWMIOg0iReDhip3A-1; Fri, 05 Nov 2021 10:35:41 -0400 X-MC-Unique: yrL8_tHWMIOg0iReDhip3A-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 12212881D52; Fri, 5 Nov 2021 14:35:23 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 37FDF60BF1; Fri, 5 Nov 2021 14:35:22 +0000 (UTC) From: Florian Weimer To: Adhemerval Zanella Cc: libc-alpha@sourceware.org Subject: Re: [PATCH 2/2] elf: Detect PT_LOAD segments that extend beyond EOF and refuse loading References: <27f078539ae2a5b390705ac6fa1a7437ae8ce97c.1636120354.git.fweimer@redhat.com> Date: Fri, 05 Nov 2021 15:35:20 +0100 In-Reply-To: (Adhemerval Zanella's message of "Fri, 5 Nov 2021 11:30:30 -0300") Message-ID: <87mtmiu0uv.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 14:35:47 -0000 * Adhemerval Zanella: > On 05/11/2021 10:59, Florian Weimer via Libc-alpha wrote: > >> @@ -1177,6 +1178,17 @@ _dl_map_object_from_fd (const char *name, const char *origname, int fd, >> = N_("ELF load command address/offset not properly aligned"); >> goto lose; >> } >> + if (__glibc_unlikely (ph->p_offset + ph->p_filesz > file_size)) >> + { >> + /* If the segment is not fully backed by the file, >> + accessing memory beyond the last full page results in >> + SIGBUS. This often happens with non-loadable ELF >> + objects containing separated debugging information >> + (which have load segments that match the original ELF >> + file). */ >> + errstring = N_("ELF load command past end of file"); >> + goto lose; >> + } > > Are these still valid objects? They are not, but we have a test that attempts to load such an object: elf/tst-debug1. There have been occasional user reports about crashes involving separated debuginfo, hence the test. > How does this object are created exactly? Seperated debuginfo: $(objpfx)tst-debug1mod1.so: $(objpfx)testobj1.so $(OBJCOPY) --only-keep-debug $< $@ > You state that it happens with 'some toolchain versions', is this > something new or has it be fixed (if it is an issue) upstream? This test is very sensitive to ELF file layout. The layout changes depending on configuration (e.g., if annobin is used). This part is expected; it is not a bug. Thanks, Florian