summaryrefslogtreecommitdiff
path: root/MdePkg
diff options
context:
space:
mode:
authorHao Wu <hao.a.wu@intel.com>2017-11-14 11:33:10 +0800
committerHao Wu <hao.a.wu@intel.com>2017-11-20 08:54:22 +0800
commit7a96634889c925b8cc83d90b8791a08354efd56b (patch)
tree289d575a5367eda9d89b1fe7424e648b2ee80fe1 /MdePkg
parent01a68fd37e79c6c7e2f342d7d2c1349325110e99 (diff)
downloadedk2-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