eyck -
As the author of the patch that apparently broke your application,
this report totally baffles me. Can you confirm that downgrading
to libx11-6 version 2:1.0.3-6 removes the problem?
Are you able to patch and rebuild test versions of libx11?
If so, one quick thing to try is to put back th
On Sat, Mar 24, 2007 at 04:29:23PM +0100, Julien Cristau wrote:
> So you're saying the remaining problem is in graphicsmagick, not Xlib?
I previously posted a patch for graphicsmagick that fixes broken.xwd.
Here is a patch for libx11 that fixes broken2.xwd.
I thought about possible ways to fixing
On Sat, Mar 24, 2007 at 04:29:23PM +0100, Julien Cristau wrote:
> So you're saying the remaining problem is in graphicsmagick, not Xlib?
I recommend further testing and investigation by others.
My analysis showed a clear bug in graphicsmagick, and I
posted a fix for it. When I retested, only brok
The root problem is integer overflow in the multiplication at
line 292 of graphicsmagick-1.1.7/coders/xwd.c. With the appended
patch, the two test cases result in the following on my amd64 sid
box:
$ gm convert broken.xwd test.png
gm convert: Memory allocation failed (broken.xwd).
$ echo $?
1
$ g
Daniel -
For both the broken.xwd and broken2.xwd files in bug #414045,
the offending operation is in libx11-1.0.3/src/ImUtil.c:505
dst++ = *src++;
and in fact it's the src pointer that is out of range.
This suggests it's "only" a DOS problem, or at worst an
information leak problem, but no dire
5 matches
Mail list logo
