From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.zytor.com (terminus.zytor.com [65.50.211.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 600DD20945C1E for ; Fri, 8 Sep 2017 06:42:39 -0700 (PDT) Received: from [IPv6:2804:7f4:c480:9cd0::2] ([IPv6:2804:7f4:c480:9cd0:0:0:0:2]) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id v88DhBS6008766 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 8 Sep 2017 06:43:14 -0700 To: Laszlo Ersek , Ruiyu Ni Cc: edk2-devel@lists.01.org, Eric Dong , hao.a.wu@intel.com, Jordan Justen , Andrew Fish , Liming Gao , Michael D Kinney , Star Zeng References: From: Paulo Alcantara Message-ID: Date: Fri, 8 Sep 2017 10:43:09 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Subject: Re: [PATCH v6 0/6] read-only UDF file system support X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 13:42:39 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Hi, On 08/09/2017 10:25, Laszlo Ersek wrote: > Ray, > > On 09/08/17 14:41, Paulo Alcantara wrote: > >> v6: >> - Fixed a bug in UdfRead() that'd pontentially break in ARM or IA32 >> by allowing caller to read more than 4GiB of data >> (i.e. BufferSize pointer is dereferenced as an UINT64 * and it's >> followed by 4 bytes that are nonzero). >> >> Repo: https://github.com/pcacjr/edk2.git >> Branch: udf-fs-v6 > > The v5-v6 diff is as follows: > >> diff --git a/MdeModulePkg/Universal/Disk/UdfDxe/File.c b/MdeModulePkg/Universal/Disk/UdfDxe/File.c >> index 2dbcff0be4a3..8b9339567f8e 100644 >> --- a/MdeModulePkg/Universal/Disk/UdfDxe/File.c >> +++ b/MdeModulePkg/Universal/Disk/UdfDxe/File.c >> @@ -325,8 +325,9 @@ UdfRead ( >> UDF_FILE_IDENTIFIER_DESCRIPTOR *NewFileIdentifierDesc; >> VOID *NewFileEntryData; >> CHAR16 FileName[UDF_FILENAME_LENGTH] = { 0 }; >> UINT64 FileSize; >> + UINT64 BufferSizeUint64; >> >> OldTpl = gBS->RaiseTPL (TPL_CALLBACK); >> >> if (This == NULL || BufferSize == NULL || (*BufferSize != 0 && >> @@ -363,18 +364,22 @@ UdfRead ( >> Status = EFI_SUCCESS; >> goto Done; >> } >> >> + BufferSizeUint64 = *BufferSize; >> + >> Status = ReadFileData ( >> BlockIo, >> DiskIo, >> Volume, >> Parent, >> PrivFileData->FileSize, >> &PrivFileData->FilePosition, >> Buffer, >> - (UINT64 *)(UINTN)BufferSize >> + &BufferSizeUint64 >> ); >> + ASSERT (BufferSizeUint64 <= MAX_UINTN); >> + *BufferSize = (UINTN)BufferSizeUint64; >> } else if (IS_FID_DIRECTORY_FILE (Parent->FileIdentifierDesc)) { >> if (ReadDirInfo->FidOffset == 0 && PrivFileData->FilePosition > 0) { >> Status = EFI_DEVICE_ERROR; >> *BufferSize = 0; > > It looks OK to me, and it builds fine for IA32, X64, ARM and AARCH64: > > Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/UdfDxe.efi > Build/ArmVirtQemu-ARM/DEBUG_GCC5/ARM/UdfDxe.efi > Build/OvmfIa32/NOOPT_GCC48/IA32/UdfDxe.efi > Build/OvmfX64/NOOPT_GCC48/X64/UdfDxe.efi > > Green light from your side? Yes - at least from what I've been testing :-) > > Paulo: you forgot to pick up Ray's R-b for patches #4 and #5, from his > v5 response > > -- it was for the entire series. D'oh - I only considered the Mde*Pkg and Nt32Pkg R-b's. Sorry. > But, I'll apply that for you. Thank you very much! Paulo