dennis-tseng99
commented
1 year ago I tried a very quick & hacky fix by statically keeping track of allocations in a fixed-size buffer
Yes. Because ReallocatePool() will copy your old buffer content to its new allocated buffer, the caller of realloc(void *ptr, size_t size) must prepare a fixed buffer by calling AllocatePool(size) with at least size bytes. Otherwise, some unknown garbage bytes will be copied to its new buffer. Many thanks.
nicholasbishop
reallocis implemented here: https://github.com/rhboot/shim/blob/main/Cryptlib/SysCall/BaseMemAllocation.c#L29It has a comment already pointing out the problem:
As currently implemented, it passes the desired size to
ReallocatePoolfor both the old and new size. This happens to work fine usually, but I found when trying to test NX protection using https://github.com/microsoft/mu_tiano_platforms it reliably faults there.I tried a very quick & hacky fix by statically keeping track of allocations in a fixed-size buffer so that
reallocknows the allocation size, and that seemed to do the trick. As far as I can tell openssl requires a functioningrealloc, so I think some variation of manually tracking allocations will be needed since UEFI doesn't provide such an interface. I don't have a PR for this yet, but figured I'd go ahead and file an issue for awareness.