From patchwork Mon Oct 3 12:19:02 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Clifton X-Patchwork-Id: 1656 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp920073wrs; Mon, 3 Oct 2022 05:19:15 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4lvT/worIJiNVPeG/z7EeJiJFPTld7uSWuw3VrUMATDV3WvySuvgk99slahXUFRCdlvFlb X-Received: by 2002:aa7:cd92:0:b0:456:cbb5:2027 with SMTP id x18-20020aa7cd92000000b00456cbb52027mr18185829edv.384.1664799555513; Mon, 03 Oct 2022 05:19:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664799555; cv=none; d=google.com; s=arc-20160816; b=RVCF/igFo1EoRQJlGY6E3O65GWy6Ow+Aq+vrXPNbGQcETFZx7PZjnzcsR0oWlgidzu cjT7oYtBzTI2ci3GiMQgfj2GJecS4b9dzRm8mQdfbPxmor0hZi7/AoKYNQ+BCnGCJLxB yR/LrTmDgSRNHwvcp3VEM+2qUyzrPwj+5JRK8cn5FK15pSQONSHP/hNNahBPmR8M5PV4 iBDEQUEzbWjRWEYwqp2EIMMIZxYZsKrrdw1q8kJnuQtGwcSpQRCM8QzGylSqro/uwx/q vdjqNXAia4TICMno9Y9ZoM1vc1ByLnZlepdxYFrGb7h1qb/Ss2AauA8u+26LI56yLdn4 Eilg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence:mime-version :message-id:date:subject:to:dmarc-filter:delivered-to:dkim-signature :dkim-filter; bh=7MUYwpjwmiBt0VQEfSJHQ7HLdsZD+SDhxtwM3di3gy4=; b=wcTAwqJTNNxbGGnfjbDUcQXFWwYkiWLvoyHCFPVbyvZhkUiK3ZfsBsb2uTmevBeGP/ ZyLTUXXLgqxwNYlfnS5lRE5m/qTN7yPIMxUIyWdOFnS6u/7O5X8cD0kL3HzJglxZKZcz qKcWbPQ6QPEuznpoZV+PRcUld/1RRWyIahCfE9FK12G3h3kGzMmqlMmH6NHRN8UZyjCP xiQ/0kXC0sK7+GkRfl9rJrDnuNmlK/UpJ/uI52zFpaT/Cp9aiYZ2hhpZXDPJZXzBQbUS 5h2W7qu2HQIggJXAhSh0DV/t7vQ61/pAZGskykXhsogDTCbLzadJ1IgLEa1L3K0s8WDN OWCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sourceware.org header.s=default header.b=yv3i8XlK; spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sourceware.org Received: from sourceware.org (ip-8-43-85-97.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id du1-20020a17090772c100b00782fa12f890si7221579ejc.727.2022.10.03.05.19.15 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Oct 2022 05:19:15 -0700 (PDT) Received-SPF: pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@sourceware.org header.s=default header.b=yv3i8XlK; spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 819C93858439 for ; Mon, 3 Oct 2022 12:19:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 819C93858439 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1664799554; bh=7MUYwpjwmiBt0VQEfSJHQ7HLdsZD+SDhxtwM3di3gy4=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=yv3i8XlKo2BHrRDLCBfRkrUbkHl3JEBZfarMG8N0F9WLO2XZJcnvP5s1k7yLVXmou /55jJXL/tCyeXBNORiyV4aNEJO9j3A4O+857I81F0QXp5X61o39rfs7w+S0CpNf4bz kGYk4ppjP4BdqhiQoVo+DskB+oZcWivZSbASygyg= X-Original-To: binutils@sourceware.org Delivered-To: binutils@sourceware.org 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 4A83B3858D32 for ; Mon, 3 Oct 2022 12:19:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4A83B3858D32 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-269-BNThcDJ4PFKvIoO8Kg4l9g-1; Mon, 03 Oct 2022 08:19:04 -0400 X-MC-Unique: BNThcDJ4PFKvIoO8Kg4l9g-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B2C1985A583 for ; Mon, 3 Oct 2022 12:19:03 +0000 (UTC) Received: from prancer.redhat.com (unknown [10.33.36.216]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 615AB4099B50 for ; Mon, 3 Oct 2022 12:19:03 +0000 (UTC) To: binutils@sourceware.org Subject: Commit: readelf: Do not load section data from offset 0 Date: Mon, 03 Oct 2022 13:19:02 +0100 Message-ID: <87lepxcd6x.fsf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_NUMSUBJECT, RCVD_IN_DNSWL_LOW, 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 X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Nick Clifton via Binutils From: Nick Clifton Reply-To: Nick Clifton Errors-To: binutils-bounces+ouuuleilei=gmail.com@sourceware.org Sender: "Binutils" X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1745668858660849169?= X-GMAIL-MSGID: =?utf-8?q?1745668858660849169?= Hi Guys, A Fedora user recently filled a bug report about readelf incorrectly handling an ELF file with no sections: https://bugzilla.redhat.com/show_bug.cgi?id=2131609 The problem turns out to be how to distinguish between a file with no sections and a file with a very large number of sections, where the real section count is held in the first entry in the section header. Setting the e_shentsize field in the file header to zero is one way to do this, but often that is just set by default to 64. So another test is to check for an e_shoff value of 0. Since the section header and file header cannot both start at file offset 0, an e_shoff field of 0 is a good indication that there are no sections. Hence this patch. Cheers Nick binutils/ChangeLog 2022-10-03 Nick Clifton * readelf.c (get_32bit_section_headers): Return false if the e_shoff field is zero. (get_64bit_section_headers): Likewise. diff --git a/binutils/readelf.c b/binutils/readelf.c index 351571c8abb..8c6c0389fe7 100644 --- a/binutils/readelf.c +++ b/binutils/readelf.c @@ -6365,6 +6365,13 @@ get_32bit_section_headers (Filedata * filedata, bool probe) /* PR binutils/17531: Cope with unexpected section header sizes. */ if (size == 0 || num == 0) return false; + + /* The section header cannot be at the start of the file - that is + where the ELF file header is located. A file with absolutely no + sections in it will use a shoff of 0. */ + if (filedata->file_header.e_shoff == 0) + return false; + if (size < sizeof * shdrs) { if (! probe) @@ -6429,6 +6436,12 @@ get_64bit_section_headers (Filedata * filedata, bool probe) if (size == 0 || num == 0) return false; + /* The section header cannot be at the start of the file - that is + where the ELF file header is located. A file with absolutely no + sections in it will use a shoff of 0. */ + if (filedata->file_header.e_shoff == 0) + return false; + if (size < sizeof * shdrs) { if (! probe)