[if gte mso 9]>

Re: [edk2] Issue in UefiPxeBcDxe

Subject: Re: [edk2] Issue in UefiPxeBcDxe

From: "Fu, Siyuan" <siyuan.fu@intel.com>

To: "El-Haj-Mahmoud, Samer" <samer.el-haj-mahmoud@hp.com>, "edk2-devel@lists.sourceforge.net" <edk2-devel@lists.sourceforge.net>

Date: 2013-07-25 17:17:06

Hi, Samer

 

The memory address Private->BootFileName points to is allocated by calling AllocateZeroPool() when using IPv6, or it’s a portion of a packet data as you said when using IPv4, so the FreePool operation only exists in the IPv6 path in EfiPxeBcStop() function. Since one PXE protocol is not allowed to start on IPv4 and IPv6 stack simultaneously, it always started on IPv4, then stopped on IPv4, or started and stopped on IPv6. So I think this piece of code should not attempt to free “a portion of a packet data”. Did you see an ASSERT happened here in your test or you just found this bug by code review?

 

 

Best Regards,

Fu, Siyuan

 

From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahmoud@hp.com]
Sent: Thursday, July 25, 2013 5:54 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Issue in UefiPxeBcDxe

 

In NetworkPkg/UefiPxeBcDxe/PxeBcImpl.c, the code attempts to free Private->BootFileName, but that was not directly allocated using UEFI memory services (it points directly to a portion of a parsed packet data, so the overall buffer for the packet was allocated, but not “BootFileName” directly.). This could cause issues that may be caught with ASSERTs in debug builds…

 

This needs to be fixed in both IPv4 and IPv6 versions in that file

 

    if (Private->BootFileName != NULL) {

      FreePool (Private->BootFileName);

      Private->BootFileName = NULL;

 }

 

 

Thanks,

--Samer