From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by mx.groups.io with SMTP id smtpd.web12.42218.1578938300275690091 for ; Mon, 13 Jan 2020 09:58:20 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gb9dTlbl; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578938299; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=76EfjnofEMzfPILXRuUai62ob7bI8SKmMeAaZm3vf7k=; b=gb9dTlbl+TrAl4+55BwpZZSAEThofPQk0NkmDo8VkCvhhOE18if6n43ERd0yBFwAoVJzn7 c6KAljEzoh1Q7oa85z1QzmNaRmivf9J8t2rGHOSRRAPj31nG2GUWZaQiGbi9p5eEvaMv+v tvCQXjzeAK/MyNJcVuIWYih3xIvYBWE= 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-337-KM5wD4XoNNCApltZe-Qfww-1; Mon, 13 Jan 2020 12:58:15 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 69A4D108592E; Mon, 13 Jan 2020 17:58:14 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-224.ams2.redhat.com [10.36.116.224]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3214F7FB5E; Mon, 13 Jan 2020 17:58:13 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] MdePkg: PE loader should zero out dest buffer on allocation To: devel@edk2.groups.io, zhiguang.liu@intel.com Cc: Jian J Wang , Hao A Wu , mhaeuser@outlook.de References: <20200113081854.9732-1-zhiguang.liu@intel.com> From: "Laszlo Ersek" Message-ID: <30c379b3-8b20-993a-cde0-e761e4e4bfec@redhat.com> Date: Mon, 13 Jan 2020 18:58:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200113081854.9732-1-zhiguang.liu@intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: KM5wD4XoNNCApltZe-Qfww-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 01/13/20 09:18, Zhiguang Liu wrote: > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1999 > > When PE loader loads image to memory, the first section of image may > not locate right next to the image header, which causes some memory > space remaining uninitialized. This is a security issue. > This patch compares the ending address of image header and the beginning > address of the first section. If there is a gap, zero out this gap. > > Cc: Jian J Wang > Cc: Hao A Wu > Signed-off-by: Zhiguang Liu > --- > MdePkg/Library/BasePeCoffLib/BasePeCoff.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c > index 07bb62f860..2cdfb4a082 100644 > --- a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c > +++ b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c > @@ -1306,6 +1306,14 @@ PeCoffLoaderLoadImage ( > // Load each section of the image > // > Section = FirstSection; > + // > + // Zero out the memory space between image header and the first section > + // > + End = (CHAR8 *)(ImageContext->ImageAddress + ImageContext->SizeOfHeaders); > + Base = PeCoffLoaderImageAddress (ImageContext, Section->VirtualAddress, TeStrippedOffset); > + if (End < Base) { > + ZeroMem (End, Base - End); > + } > for (Index = 0; Index < NumberOfSections; Index++) { > // > // Read the section > CC'ing Marvin Thanks Laszlo