diff options
author | Nate DeSimone <nathaniel.l.desimone@intel.com> | 2023-08-30 07:51:43 -0700 |
---|---|---|
committer | mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> | 2023-08-31 19:35:19 +0000 |
commit | beafabdae49c873adecdb7511dbebe9d4ff5c8f0 (patch) | |
tree | 282867dfa2da34d27106891bb818fe46f1917691 /MdeModulePkg | |
parent | 4c8144dd665619731b6c3c19f4f1ae664b69fa4b (diff) | |
download | edk2-beafabdae49c873adecdb7511dbebe9d4ff5c8f0.zip edk2-beafabdae49c873adecdb7511dbebe9d4ff5c8f0.tar.gz edk2-beafabdae49c873adecdb7511dbebe9d4ff5c8f0.tar.bz2 |
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')
-rw-r--r-- | MdeModulePkg/Core/Dxe/Hand/Locate.c | 6 |
1 files changed, 5 insertions, 1 deletions
diff --git a/MdeModulePkg/Core/Dxe/Hand/Locate.c b/MdeModulePkg/Core/Dxe/Hand/Locate.c index a29010a..8f20c63 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 ();
|