diff options
author | Hao Wu <hao.a.wu@intel.com> | 2017-11-14 11:33:10 +0800 |
---|---|---|
committer | Hao Wu <hao.a.wu@intel.com> | 2017-11-20 08:54:22 +0800 |
commit | 7a96634889c925b8cc83d90b8791a08354efd56b (patch) | |
tree | 289d575a5367eda9d89b1fe7424e648b2ee80fe1 /MdePkg | |
parent | 01a68fd37e79c6c7e2f342d7d2c1349325110e99 (diff) | |
download | edk2-7a96634889c925b8cc83d90b8791a08354efd56b.zip edk2-7a96634889c925b8cc83d90b8791a08354efd56b.tar.gz edk2-7a96634889c925b8cc83d90b8791a08354efd56b.tar.bz2 |
MdeModulePkg/UdfDxe: Avoid possible loss track of allocated buffer
In function FindFileEntry():
Instead of using the function parameter 'FileEntry', use a local
variable to store the buffer allocated for disk read operation.
For the below calling stack:
UdfOpenVolume() -> FindRootDirectory() -> FindFileEntry()
In FindFileEntry(), the call to 'DiskIo->ReadDisk()' is possible (e.g.
media change for a CD/DVD ROM device) to trigger a re-install of the
BlockIO(2) protocol which will further lead to a call of the BindingStop()
& BingdingStart() of the UdfDxe driver.
Meanwhile, for the above listed calling stack, the '**FileEntry'
parameter passed into FindFileEntry() is '&PrivFsData->Root'. 'PrivFsData'
is a driver-managed private data, it will be freed in BindingStop() and
re-allocate in BingdingStart().
In such case, if '*FileEntry' is used to store the allocated buffer, the
information will be lost if 'DiskIo->ReadDisk()' triggers a re-install of
the BlockIO(2) protocol. The subsequent call of the FreePool API:
FreePool (*FileEntry);
will cause issues.
This commit uses a local variable to store the allocated buffer.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Diffstat (limited to 'MdePkg')
0 files changed, 0 insertions, 0 deletions