naruto-lgtm opened a new pull request, #1407: URL: https://github.com/apache/poi/pull/1407
Repro: a PICT blip in a .ppt whose metafile header claims a wmfSize near 2 GB, or an EMF StretchDIBits/BitBlt-style record with non-contiguous bitmap header and bits whose cbBmi + cbBits add up to near 2 GB. Calling `getData()` on the picture, or parsing the EMF, fails with `OutOfMemoryError: Java heap space` from a few bytes of input. Cause: `PICT.read` presizes its `UnsynchronizedByteArrayOutputStream` with `header.getWmfSize()`, and `HemfFill.readBitmap` presizes with `cbBmi + cbBits`. Both are taken straight from the file and allocated before `Metafile.getMaxRecordLength()` / `HwmfPicture.getMaxRecordLength()` is checked, so the limits don't apply to this allocation. Fix: both values are only buffer hints (the copy stops at the real end of data, and `HwmfBitmapDib.init` already accepts a recordSize larger than the body), so clamp the hint to the existing max record length instead of rejecting. Valid files parse the same. Same idea as the `safelyAllocateCheck` that `HemfEmbeddedIterator` already does before `setBufferSize(totalSize)`. Tests: `TestMetafileInflateSizeLimit` patches wmfSize in cow.pict and checks `getData()` is unchanged. The new `TestHemfFill` calls `readBitmap` on a 16-byte record with cbBmi + cbBits near 2 GB. Both hit OutOfMemoryError before this change. `:poi-scratchpad:check` passes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
