Skip to content

fix(pngimage): correct 16-bit sBIT handling in compare_read - #914

Open
Samin061 wants to merge 1 commit into
pnggroup:libpng18from
Samin061:pngimage-sbit-oob
Open

fix(pngimage): correct 16-bit sBIT handling in compare_read#914
Samin061 wants to merge 1 commit into
pnggroup:libpng18from
Samin061:pngimage-sbit-oob

Conversation

@Samin061

Copy link
Copy Markdown

compare_read fills sig_bits with one entry per colour component, but for 16-bit images the sBIT sanity check loops once per byte and the case 16 expansion writes sig_bits[2b+1]/[2b+0] starting from b == channels. Feeding pngimage a 16-bit RGBA file that carries an sBIT chunk drives b to 4, storing two bytes past the 8-byte sig_bits stack array; AddressSanitizer reports a stack-buffer-overflow at the write. Bound the check by the real component count and expand into sig_bits[2b-1]/[2b-2] from sig_bits[b-1] so the eight bytes are produced within the array.

compare_read fills sig_bits with one entry per colour component, but for 16-bit images the sBIT check looped once per byte and the big-endian expansion wrote sig_bits[2*b+1]/[2*b+0] starting from b == channels. A 16-bit RGBA image with an sBIT chunk drives b to 4 and stores two bytes past the 8-byte sig_bits array. Bound the check by the component count and expand into sig_bits[2*b-1]/[2*b-2] from sig_bits[b-1].
@jbowler

jbowler commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

The change on line 1162 makes no sense whatsoever; 'b' is incremented.

The change is also isolated from the rest of the changes; it is located within a separate loop.

The other change implies an off-by-one error but the explanation is utterly unrelated. This looks to me like something generated by an AI. I'm not paid to train AIs so I will not comment further.

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.

2 participants