On Wed, 30 Sep 2026 12:18:52 GMT, Timofei Fedotov <[email protected]> wrote:
> SplashDecodeGif() uses gif->SBackGroundColor as an index into > colorMap->Colors when handling GIF_DISPOSE_BACKGND. > > The background colour index is read from the GIF Logical Screen Descriptor > and may contain a value from 0 to 255. The value is not validated against > colorMap->ColorCount before indexing the colour table. A malformed GIF with a > small colour table and an out-of-range SBackGroundColor can therefore cause > an out-of-bounds heap read. > > For example, a GIF with a colour table containing two entries and > SBackGroundColor = 255 causes colorMap->Colors[255] to be accessed. The > resulting colour value is subsequently used to fill the disposed frame > background, exposing adjacent heap contents in the rendered splash image. > > Add a bounds check ensuring SBackGroundColor is within ColorCount before > indexing the colour table. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). src/java.desktop/share/native/libsplashscreen/splashscreen_gif.c line 285: > 283: colorMap->Colors && > 284: transparentColor < 0 && > 285: gif->SBackGroundColor < colorMap->ColorCount) { Looks like gif->SBackGroundColor originated from an unsigned char, so we should not need to check for < 0 .. so this should be OK. Don't we need a test for this ? It may not crash reliably, but a gif with a small colormap size and invalid b/g color might occasionally do so .. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33145#discussion_r4149010988
