r/ExploitDev • u/lcpjj_ • 5h ago
Heap overflow in EDK2’s Brotli decompressor: the CVE-2021-28211 fix was applied to LZMA and never to Brotli
I found a heap buffer overflow in the Brotli glue code in EDK2 (BrotliDecompress.c). It has been there since 2017 and it’s still unfixed at HEAD.
Some background. CVE-2021-28211 was a heap overflow in EDK2’s LZMA decompressor. GetInfo took a UINT64 decoded size and truncated it to UINT32 with no check, so the decoder could write past the buffer that had been allocated. The fix added a MAX_UINT32 check and bounded the output.
The Brotli decompressor was added earlier with the same structure, and it never got the same fix. BrotliDecompressInternal writes into the destination buffer with no limit. It just runs until the stream ends, whatever size the buffer is. If you control the firmware image, you declare a small output size (or use the UINT64 to UINT32 truncation), the DXE core allocates that much, and the decompressor writes past it. That’s a heap overflow in DXE, before Secure Boot.
I have an ASAN-confirmed PoC. I also built an end-to-end demo that corrupts adjacent pool objects in a controlled way: it hijacks function pointers and overwrites the Secure Boot flag with bytes I choose.
The catch is that I couldn’t find anyone using it. I scanned 200 shipping firmware images from LVFS and searched public GitHub repos, and found zero platforms that use Brotli GUIDed sections. The code is in the tree but looks unused in practice. That’s one scan of 200 images, so it doesn’t rule out private platforms. I still think it should be fixed, because anyone who adopts Brotli later would inherit the bug.
Write-up, PoC, demo and the LVFS scan: https://github.com/lukr54/edk2-security
EDK2 issue: tianocore/edk2#13391

