summaryrefslogtreecommitdiffstats
path: root/MdeModulePkg/Core
diff options
context:
space:
mode:
authorNate DeSimone <nathaniel.l.desimone@intel.com>2023-08-30 07:51:43 -0700
committermergify[bot] <37929162+mergify[bot]@users.noreply.github.com>2023-08-31 19:35:19 +0000
commitbeafabdae49c873adecdb7511dbebe9d4ff5c8f0 (patch)
tree282867dfa2da34d27106891bb818fe46f1917691 /MdeModulePkg/Core
parent4c8144dd665619731b6c3c19f4f1ae664b69fa4b (diff)
downloadedk2-beafabdae49c873adecdb7511dbebe9d4ff5c8f0.tar.gz
edk2-beafabdae49c873adecdb7511dbebe9d4ff5c8f0.tar.bz2
edk2-beafabdae49c873adecdb7511dbebe9d4ff5c8f0.zip
MdeModulePkg: Fix memory leak in LocateHandleBuffer()
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4543 REF: https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#efi-boot-services-locatehandlebuffer CoreLocateHandleBuffer() can in certain cases, return an error and not free an allocated buffer. This scenario occurs if the first call to InternalCoreLocateHandle() returns success and the second call returns an error. On a successful return, LocateHandleBuffer() passes ownership of the buffer to the caller. However, the UEFI specification is not explicit about what the expected ownership of this buffer is in the case of an error. However, it is heavily implied by the code example given in section 7.3.15 of v2.10 of the UEFI specificaton that if LocateHandleBuffer() returns a non-successful status code then the ownership of the buffer does NOT transfer to the caller. This code example explicitly refrains from calling FreePool() if LocateHandleBuffer() returns an error. From a practical standpoint, it is logical to assume that a non-successful status code indicates that no buffer of handles was ever allocated. Indeed, in most error cases, LocateHandleBuffer() does not go far enough to get to the point where a buffer is allocated. Therefore, all existing users of this API must already be coded to support the case of a non-successful status code resulting in an invalid handle buffer being returned. Therefore, this change will not cause any backwards compatibility issues with existing code. In conclusion, this boils down to a fix for a memory leak that also brings the behavior of our LocateHandleBuffer() implementation into alignment with the original intentions of the UEFI specification authors. Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Diffstat (limited to 'MdeModulePkg/Core')
-rw-r--r--MdeModulePkg/Core/Dxe/Hand/Locate.c6
1 files changed, 5 insertions, 1 deletions
diff --git a/MdeModulePkg/Core/Dxe/Hand/Locate.c b/MdeModulePkg/Core/Dxe/Hand/Locate.c
index a29010a545..8f20c6332d 100644
--- a/MdeModulePkg/Core/Dxe/Hand/Locate.c
+++ b/MdeModulePkg/Core/Dxe/Hand/Locate.c
@@ -1,7 +1,7 @@
/** @file
Locate handle functions
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2006 - 2023, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
@@ -730,6 +730,10 @@ CoreLocateHandleBuffer (
*NumberHandles = BufferSize / sizeof (EFI_HANDLE);
if (EFI_ERROR (Status)) {
*NumberHandles = 0;
+ if (*Buffer != NULL) {
+ CoreFreePool (*Buffer);
+ *Buffer = NULL;
+ }
}
CoreReleaseProtocolLock ();