Control: retitle -1 imlib2: CVE-2016-3993: off-by-one OOB read in
__imlib_MergeUpdate
Hi,
On Sat, Apr 02, 2016 at 09:18:09PM +0300, Yuriy M. Kaminskiy wrote:
> Package: libimlib2
> Version: 1.4.6-2+deb8u1
> Severity: normal
> Tags: upstream patch
>
> Dear Maintainer,
>
> 1) I re-compiled imlib2 package with debug information,
> 2) compiled and installed tests (data, src/bin),
> 3) run `valgrind imlib2_test`,
> 4) moved mouse to right lower corner of window;
>
> ==16086== Invalid read of size 1
> ==16086== at 0x4E79C4E: __imlib_MergeUpdate (in
> /usr/lib/x86_64-linux-gnu/libImlib2.so.1.4.6)
> ==16086== by 0x401773: main (in /usr/bin/imlib2_test)
> ==16086== Address 0x9d20360 is 0 bytes after a block of size 1,200
> alloc'd
> ==16086== at 0x4C28C20: malloc (vg_replace_malloc.c:296)
> ==16086== by 0x4E798E3: __imlib_MergeUpdate (in
> /usr/lib/x86_64-linux-gnu/libImlib2.so.1.4.6)
> ==16086== by 0x401773: main (in /usr/bin/imlib2_test)
>
> In gdb, it points to src/lib/updates.c:
>
> | for (xx = x + 1, ww = 1; |
> >| (T(xx, y).used & T_USED) && (xx < tw); xx++,|
> | for (yy = y + 1, hh = 1, ok = 1; |
>
> xx is 20 and tw is 20, so T(xx, y) addresses one byte out of buffer.
>
> Pretty obvious, off-by-one error due to swapped condition order.
> In unlucky case, this can result in application crash.
> Security implications: very minor, DoS at most, only for application drawing
> images using coordinates from untrusted source ("drawing images from
> untrusted sources" by itself is safe).
> Two *alternative* patches attached (apply only *one* of them).
> TODO: I have not tried to search for similar pattern over codebase yet.
>
> Note: there are no changes affecting this code in 1.4.7 (sid) or 1.4.8
> (upstream).
CVE-2016-3993 has been assigned for this issue.
Regards,
Salvatore
