Page MenuHomePhabricator

imlib2: cannot rescale+render images > 32767 width
Closed, ResolvedPublic

Description

This is Debian bug https://bugs.debian.org/783254 reported by Lars Stoltenow.

His steps to reproduce:

convert -size 32770x100 xc:white test.png
feh --fullscreen test.png

Apparently the latest version of imagemagick does no longer allow users to create images that exceed a certain limit but it should be possible to create such images with other means. He also provided a way to fix/work around it

https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=783254;filename=imlib-resize-32767.diff;msg=5

Here is the full bug report:

rendering an imlib image to a X11 window while simultaneously scaling it, causes
a crash when the image width is > 32768 (or 32767 or so).

The bug originally appeared when using feh to view a wide PNG image in
fullscreen (causing it to be downsampled while rendering).

The (apparent) cause of the crash is the __imlib_CalcXPoints calculating
offsets (into image data I think) incorrectly. For not-so-wide images, all
offsets are positive, which makes sense. For wider images, all but the first
offsets are negative, which subsequently causes out-of-bounds memory accesses
and a crash.

I guess this is because the calculations happen with int = 32 bit (even on
amd64). Several intermediate calculations shift left by 16 -> sign bit flips
for > 32768 -> calculated offset becomes negative. (The resulting value is
right shifted by 16 later again, but then of course it is still negative).

A first quick fix that doesn't appear to completely fall apart is attached.
It appears to fix the problem, however I am not sure if there are other parts
that should also use 64 bit numbers.

apoleon created this task.Mar 7 2018, 6:24 AM
apoleon triaged this task as Normal priority.
kwo closed this task as Resolved.Mar 10 2018, 3:19 AM

This was reported 24 Apr 2015 so that was probably imlib2 1.4.6/7/8.
In 1.4.9 the maximum image dimension was lowered to 32767, so the shift/overflow/crash problem should no longer occur.
However, it appears that the png loader is buggy so imlib_load_image("test.png") returns an invalid image (no pixel data) instead of a null pointer (libpng apparently dislikes the image).
I'll deal with that separately.

kwo added a comment.Mar 10 2018, 5:28 AM

Correction - strike "(libpng apparently dislikes the image)" - the png loader just doesn't interact properly with libpng in various error cases.

kwo added a project: Restricted Project.Mar 10 2018, 12:22 PM