summaryrefslogtreecommitdiffstats
path: root/BaseTools/Source/Python
diff options
context:
space:
mode:
authorArd Biesheuvel <ard.biesheuvel@linaro.org>2017-03-16 11:35:28 +0000
committerArd Biesheuvel <ard.biesheuvel@linaro.org>2017-03-17 18:50:55 +0000
commit3f2ae009ec66430f13bd24f2de475965eb3bc6df (patch)
tree06feffbf159d0cb61920ecfa1aab93a1665f1c57 /BaseTools/Source/Python
parent01eb3f39bbcc5b6474d69cff3922be8eb1856636 (diff)
downloadedk2-3f2ae009ec66430f13bd24f2de475965eb3bc6df.tar.gz
edk2-3f2ae009ec66430f13bd24f2de475965eb3bc6df.tar.bz2
edk2-3f2ae009ec66430f13bd24f2de475965eb3bc6df.zip
MdeModulePkg/DxeCore: deal with allocations spanning several memmap entries
When attempting to perform page allocations using AllocateAddress, we fail to check whether the entire region is free before splitting the region. This may lead to memory being leaked further into the routine, when it turns out that one of the memory map entries intersected by the region is already occupied. In this case, prior conversions are not rolled back. For instance, starting from this situation 0x000040000000-0x00004007ffff [ConventionalMemory ] 0x000040080000-0x00004009ffff [Boot Data ] 0x0000400a0000-0x000047ffffff [ConventionalMemory ] a failed EfiLoaderData allocation @ 0x40000000 that covers the BootData region will fail, but leave the first part of the allocation converted, so we end up with 0x000040000000-0x00004007ffff [Loader Data ] 0x000040080000-0x00004009ffff [Boot Data ] 0x0000400a0000-0x000047ffffff [ConventionalMemory ] even though the AllocatePages() call returned an error. So let's check beforehand that AllocateAddress allocations are covered by a single memory map entry, so that it either succeeds or fails completely, rather than leaking allocations. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Star Zeng <star.zeng@intel.com>
Diffstat (limited to 'BaseTools/Source/Python')
0 files changed, 0 insertions, 0 deletions