From: "Kinney, Michael D" <michael.d.kinney@intel.com>
To: "Ni, Ruiyu" <ruiyu.ni@intel.com>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
"Kinney, Michael D" <michael.d.kinney@intel.com>
Cc: "Carsey, Jaben" <jaben.carsey@intel.com>
Subject: Re: [Patch] ShellPkg/Hexedit: Fix FreePool() ASSERT() when writing disk
Date: Thu, 29 Sep 2016 02:11:54 +0000 [thread overview]
Message-ID: <E92EE9817A31E24EB0585FDF735412F56481D8E5@ORSMSX113.amr.corp.intel.com> (raw)
In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D58E0CE24@SHSMSX104.ccr.corp.intel.com>
Ray,
I agree that the contents of the device path buffer is not changed.
&DupDevicePath is passed into LocateDevicePath() and the
value pointed to by &DupDevicePath is modified.
Then the call to FreePool(DupDevicePath) uses a different
DupDevicePath value than was returned by
DuplicateDevicePath(DevicePath). That generated CR macro
ASSERT().
Mike
> -----Original Message-----
> From: Ni, Ruiyu
> Sent: Wednesday, September 28, 2016 7:00 PM
> To: Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
> Cc: Carsey, Jaben <jaben.carsey@intel.com>
> Subject: RE: [Patch] ShellPkg/Hexedit: Fix FreePool() ASSERT() when writing disk
>
> Mike,
> BS.LocateDevicePath() doesn't change the device path content.
> So I think the Duplication/Free of device path is not needed.
>
> Regards,
> Ray
>
> >-----Original Message-----
> >From: Kinney, Michael D
> >Sent: Thursday, September 29, 2016 8:38 AM
> >To: edk2-devel@lists.01.org
> >Cc: Carsey, Jaben <jaben.carsey@intel.com>; Ni, Ruiyu <ruiyu.ni@intel.com>
> >Subject: [Patch] ShellPkg/Hexedit: Fix FreePool() ASSERT() when writing disk
> >
> >The HDiskImageSave() function copies a device path using
> >DuplicateDevicePath() and passes that device path to
> >gBS->LocateDevicePath() that changes the value of the
> >device path pointer. When FreePool() is called with the
> >modified device path pointer, the FreePool() service
> >generates an ASSERT() because the signature for the pool
> >head can not be found.
> >
> >The function HDiskImageRead() immediately above
> >HDiskImageSave() has the correct algorithm that uses an
> >additional local variable called DupDevicePathForFree to
> >preserve the pointer to the allocated buffer so it can
> >be used in the call to FreePool().
> >
> >Bug: <https://bugzilla.tianocore.org/show_bug.cgi?id=131>
> >
> >Cc: Jaben Carsey <jaben.carsey@intel.com>
> >Cc: Ruiyu Ni <ruiyu.ni@intel.com>
> >Contributed-under: TianoCore Contribution Agreement 1.0
> >Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
> >---
> > ShellPkg/Library/UefiShellDebug1CommandsLib/HexEdit/DiskImage.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> >diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/HexEdit/DiskImage.c
> >b/ShellPkg/Library/UefiShellDebug1CommandsLib/HexEdit/DiskImage.c
> >index a50b52f..bc74a4f 100644
> >--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/HexEdit/DiskImage.c
> >+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/HexEdit/DiskImage.c
> >@@ -343,6 +343,7 @@ HDiskImageSave (
> >
> > CONST EFI_DEVICE_PATH_PROTOCOL *DevicePath;
> > EFI_DEVICE_PATH_PROTOCOL *DupDevicePath;
> >+ EFI_DEVICE_PATH_PROTOCOL *DupDevicePathForFree;
> > EFI_BLOCK_IO_PROTOCOL *BlkIo;
> > EFI_STATUS Status;
> > EFI_HANDLE Handle;
> >@@ -364,12 +365,13 @@ HDiskImageSave (
> > return EFI_INVALID_PARAMETER;
> > }
> > DupDevicePath = DuplicateDevicePath(DevicePath);
> >+ DupDevicePathForFree = DupDevicePath;
> >
> > //
> > // get blkio interface
> > //
> > Status = gBS->LocateDevicePath(&gEfiBlockIoProtocolGuid,&DupDevicePath,&Handle);
> >- FreePool(DupDevicePath);
> >+ FreePool(DupDevicePathForFree);
> > if (EFI_ERROR (Status)) {
> > // StatusBarSetStatusString (L"Read Disk Failed");
> > return Status;
> >--
> >2.6.3.windows.1
next prev parent reply other threads:[~2016-09-29 2:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-29 0:38 [Patch] ShellPkg/Hexedit: Fix FreePool() ASSERT() when writing disk Michael Kinney
[not found] ` <734D49CCEBEEF84792F5B80ED585239D58E0CE24@SHSMSX104.ccr.corp.intel.com>
2016-09-29 2:11 ` Kinney, Michael D [this message]
2016-09-29 2:36 ` Ni, Ruiyu
2016-09-29 2:48 ` Kinney, Michael D
2016-09-29 2:51 ` Ni, Ruiyu
[not found] ` <E92EE9817A31E24EB0585FDF735412F56481EC72@ORSMSX113.amr.corp.intel.com>
2016-10-03 18:24 ` Carsey, Jaben
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E92EE9817A31E24EB0585FDF735412F56481D8E5@ORSMSX113.amr.corp.intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox