Skip to content

IMAGING-379: Fix int overflow that bypasses the JPEG raster allocation guard - #570

Open
sharanggupta wants to merge 2 commits into
apache:masterfrom
sharanggupta:harden-jpeg-allocation
Open

sharanggupta wants to merge 2 commits into
apache:masterfrom
sharanggupta:harden-jpeg-allocation

Conversation

@sharanggupta

Copy link
Copy Markdown

JpegDecoder guards the output raster with Allocator.check(Integer.BYTES * width * height), but that product is computed in int and overflows for large SOF dimensions (e.g. 0x8000 x 0x8000 wraps to 0), so the guard passes and Raster.createPackedRaster then allocates from the raw dimensions: an uncontrolled multi-gigabyte allocation from a tiny crafted JPEG. This computes the request in long and uses the existing overflow-safe two-argument Allocator.check overload. Adds a JpegDecoderTest case that fails without the change.

Reported privately to the ASF security team, who confirmed the analysis and pointed to IMAGING-379 as the right home for this hardening (resource exhaustion is out of scope as a security report), suggesting this public contribution.

JpegDecoder guarded the output raster with
Allocator.check(Integer.BYTES * width * height), but that product is
computed in int and overflows for large SOF dimensions (0x8000 x 0x8000
wraps to 0), so the guard passes and Raster.createPackedRaster then
allocates from the raw dimensions. Compute the request in long and use
the overflow-safe two-argument Allocator.check overload.

Assisted-By: Claude (Anthropic)
Assisted-By: Claude (Anthropic)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant