Skip to content

hdr: reject modern RLE scanlines whose marker width does not match - #3121

Open
mamicicekel wants to merge 1 commit into
image-rs:mainfrom
mamicicekel:fix/hdr-rle-scanline-width
Open

mamicicekel wants to merge 1 commit into
image-rs:mainfrom
mamicicekel:fix/hdr-rle-scanline-width

Conversation

@mamicicekel

Copy link
Copy Markdown

Modern Radiance RGBE scanlines start with 02 02 plus a 16-bit width. read_scanline used that prefix only to pick the new RLE path, so a marker whose width did not match the image still decoded when the following runs produced the right number of pixels.

The encoded width is now compared with the scanline buffer before the four component runs are expanded. Unit tests cover a matching marker and both a shorter and a longer mismatch.

Fixes #3119.

This change was produced with LLM assistance.

Made with Cursor

The Radiance per-component RLE marker encodes the scanline width in
its last two bytes, but read_scanline only used those bytes to detect
the new encoding. A crafted marker could therefore decode as long as
the following runs still filled the buffer. Compare the encoded width
before expanding the four components.

Fixes image-rs#3119.

Co-authored-by: Cursor <cursoragent@cursor.com>

This branch has not been deployed

No deployments
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.

HDR decoder accepts RLE scanline marker with width mismatching image width

1 participant