After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 768738 - Integer overflow in DecodeHeader
Integer overflow in DecodeHeader
Product: gdk-pixbuf
Classification: Platform
Component: loaders
Other Linux
: Normal critical
: ---
Assigned To: gdk-pixbuf-maint
Depends on:
Reported: 2016-07-12 15:17 UTC by Tobias Mueller
Modified: 2019-03-06 17:10 UTC
See Also:
GNOME target: ---
GNOME version: ---

log (1016 bytes, application/x-xz)
2016-07-12 15:20 UTC, Tobias Mueller
patch (1.33 KB, patch)
2016-07-12 15:20 UTC, Tobias Mueller
committed Details | Review
poc (104 bytes, application/gzip)
2016-07-12 15:22 UTC, Tobias Mueller

Description Tobias Mueller 2016-07-12 15:17:37 UTC
Comment 1 Tobias Mueller 2016-07-12 15:19:21 UTC
We received the report on from Hanno Boeck:

A BMP image with a large image width can cause an overflow in the
calculation of State->LineWidth in the function DecodeHeader().

This is the code:
        if (State->Type == 32)
                State->LineWidth = State->Header.width * 4;
        else if (State->Type == 24)
                State->LineWidth = State->Header.width * 3;
[...] (more lines for other bits per pixel sizes)

If State->Header.width * [whatever] is bigger than 2^32 this will cause
an overflow, subsequently skipping sanity checks and causing invalid
memory reads in Oneline32.

I have attached a BMP sample file that will trigger this bug.
gdk-pixbuf needs to be compiled with address sanitizer to show the bug.
I'll also attack the address sanitizer error message.

Also attached is a proposed patch to fix the issue. I have unified the
if-block for all cases where the bits per pixel are one byte or more,
introduce a temporary variable bytesPerPixel and will do an overflow
check. If that fails an error is returned.

This bug was discovered with the help of american fuzzy lop and address
Comment 2 Tobias Mueller 2016-07-12 15:20:17 UTC
Created attachment 331354 [details]
Comment 3 Tobias Mueller 2016-07-12 15:20:52 UTC
Created attachment 331355 [details] [review]
Comment 4 Tobias Mueller 2016-07-12 15:22:12 UTC
Created attachment 331356 [details]