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.133.124]) by sourceware.org (Postfix) with ESMTPS id 0EC973858D28 for ; Fri, 5 Nov 2021 14:32:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0EC973858D28 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-170-tkLVvYKyOTGJq2qJDuWRUA-1; Fri, 05 Nov 2021 10:31:57 -0400 X-MC-Unique: tkLVvYKyOTGJq2qJDuWRUA-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 E5CD410168C0; Fri, 5 Nov 2021 14:31:56 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 18B4560C81; Fri, 5 Nov 2021 14:31:55 +0000 (UTC) From: Florian Weimer To: "H.J. Lu" Cc: GNU C Library 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:31:54 +0100 In-Reply-To: (H. J. Lu's message of "Fri, 5 Nov 2021 07:26:47 -0700") Message-ID: <87r1buu10l.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:32:02 -0000 * H. J. Lu: > On Fri, Nov 5, 2021 at 7:01 AM Florian Weimer via Libc-alpha > wrote: >> >> We occasionally see elf/tst-debug1 failing with a SIGBUS error >> with some toolchain versions (recently on aarch64 only). This test >> tries to emulate loading separated debuginfo, but whether the test >> object triggers the crash depends on many factors. Accurately >> rejected separated debuginfo in dlopen probably needs ELF markup, >> at least if this is to be done efficiently using program headers >> only. But this change still improves user experience slightly. >> We already obtain the file size from the kernel in most cases, >> so no additional system call is added. > > Under what conditions does the test trigger SIGBUS? If the separated debuginfo object is shorter than the original object, and the dynamic loader tries to access something in the load segment that extends beyond the end of the file. I suspect triggering the actual crash depends on placement of the dynamic segments and of relocation targets. > Does your patch makes the test pass or just turn SIGBUS into a > different failure? It makes the test pass because the dlopen reports the new error for this particular error condition. Of course, the test can still crash due to invalid data in the dynamic segment if we are unlucky. Thanks, Florian