Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure
On Sat, Dec 02, 2023 at 08:35:38PM +0200, Niko Tyni wrote:
> >From
> >https://sources.debian.org/src/libimager-perl/1.020%2Bdfsg-1/TIFF/imtiff.c/#L302
>
> static toff_t sizeproc(thandle_t x) {
> return 0;
> }
>
> which is used as the TIFFClientOpen() argument in i_readtiff_wiol():
>
>
> https://sources.debian.org/src/libimager-perl/1.020%2Bdfsg-1/TIFF/imtiff.c/#L710
>
> So it looks like libimager-perl is always saying the file size is 0,
> and this hasn't hurt earlier but now does with the src:tiff CVE-2023-6277
> patch.
>
> Not sure where this leaves us, but I've just reported it at
>
> https://github.com/tonycoz/imager/issues/522
Fixed in 1.022, please let me know if you have any more problems.
d54ea521f63ec1ed7d8c0fd11c23507600d51143 should be safe to cherry pick
back to 1.020 if you don't want all of the 1.021 TIFF changes in
the debian stable libimager-perl.
Thanks,
Tony
Bug#900739: crashing in toke.c, keyword plugin pointer is left pointing to an XS module that's been unloaded
On Mon, Jun 04, 2018 at 09:31:06PM +0100, Dominic Hargreaves wrote: > Thanks for the detailed analysis both! Given that the fix is accidental, > and not in a released version of perl yet, I'm not sure whether this > belongs in a stable update. That said, maybe there is no more correct > place for a fix for this issue to live? 5.26.2 has the fix as v5.26.1-61-g1e4ebce09b maint-5.24 received only a very small set of changed outside of Module::CoreList changes and the security fixes for the last release. Tony
Bug#900739: crashing in toke.c, keyword plugin pointer is left pointing to an XS module that's been unloaded
The underlying cause appears to be that libm is referencing _LIB_VERSION in libperl. I suspect the Oracle client libraries have dlopen()ed a library that depends on libm, and that isn't dlclosed() when mod_perl unloads DBD::Oracle. So the process that leads to the crash: 1) Apache starts it configuration check[1], loads mod_perl, which implicitly loads libperl (with PL_keyword_plugin set to its default) 2) mod_perl runs the startup script, loading Syntax::Keyword::Try (which points PL_keyword_plugin at its keyword handler) and DBD::Oracle (which presumably dlopen()s a shared object that depends on libm). 3) Apache unloads mod_perl, which unloads the shared objects for Syntax::Keyword::Try and DBD::Oracle. Since something still loaded depends on libm, and that depends on the _LIB_VERSION symbol defined by libperl, libperl remains loaded. PL_keyword_plugin now points to where the Syntax::Keyword::Try keyword handler *used* to be. 4) Apache loads mod_perl again, and attempts to parse the perl startup script. Since PL_keyword_plugin points to unmapped memory, libperl segfaults. Without something else depending on libm, libperl would normally be unloaded at step 3), and step 4) would reload libperl, with PL_keyword_plugin pointing at the default keyword plugin function. The patch incidentally prevents libm depending on the _LIB_VERSION symbol in libperl, so libperl can unload when mod_perl unloads. Tony [1] https://wiki.apache.org/httpd/ModuleLife
Bug#847397: libimager-perl FTBFS on mips/mipsel: Failed 10/66 test programs
On Fri, Dec 09, 2016 at 01:01:01AM +0100, gregor herrmann wrote: > On Fri, 09 Dec 2016 01:14:23 +0200, Niko Tyni wrote: > > > TL;dr: this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176 > > Oh. > > > > > Otherwise a backtrace for a -g build from the crash would be handy: > > > > perl Makefile.PL OPTIMIZE=-g > > It goes away without the default optimization level -O2. > > > > On eller.debian.org, mipsel chroot, with OPTIMIZE="-g -O2": > [..] > > I think a want to book a workshop "gdb for harmless perl packagers" > :) > > > Unfortunately gcc doesn't seem to have a targeted option to disable this > > optimization. Building with -O0 on mips and mipsel is probably the best > > workaround we have (-O1 isn't enough.) > > I now cam up with the following change to d/rules: > > +# #847397 > +DEB_HOST_ARCH = $(shell dpkg-architecture -qDEB_HOST_ARCH) > +NOOPT = mips mipsel amd64 > +ifneq (,$(filter $(DEB_HOST_ARCH), $(NOOPT))) > +export DEB_CFLAGS_MAINT_STRIP:=-O2 > +export DEB_CFLAGS_MAINT_APPEND:=-O0 > +endif > > (committed and pushed). Does this make sense (if I remove the > debugging amd64 again, or course)? > That certainly looks like a sensible workaround. Is there some mechanism that will remove it if the gcc (or perhaps kernel) bug is fixed? Tony
Bug#847397: libimager-perl FTBFS on mips/mipsel: Failed 10/66 test programs
On Wed, Dec 07, 2016 at 10:27:33PM +0200, Adrian Bunk wrote: > Source: libimager-perl > Version: 1.005+dfsg-1 > Severity: serious > > https://buildd.debian.org/status/package.php?p=libimager-perl=sid > > ... > Test Summary Report > --- > t/150-type/030-double.t (Wstat: 10 Tests: 16 Failed: 0) > Non-zero wait status: 10 > Parse errors: Bad plan. You planned 136 tests but ran 16. This looks like an unaligned access from the tests that failed, probably in imgdouble.c. Would it be possible to get access to this (or similar) hardware to debug on? Otherwise a backtrace for a -g build from the crash would be handy: perl Makefile.PL OPTIMIZE=-g make gdb --args perl -Mblib t/150-type/030-double.t r bt Thanks, Tony
Bug#823481: libimager-perl: FTBFS: t/200-file/400-basic.t failure
On Thu, May 05, 2016 at 10:05:55AM +0300, Niko Tyni wrote: > t/200-file/400-basic.t .. > 1..262 > [...] > # type gif > #opening Format: gif, options: file=>GIF/testimg/expected.gif > ok 69 # Imager=HASH(0x1b10430) > ok 70 # opening GIF/testimg/expected.gif > ok 71 # > ok 72 # seek after read > ok 73 # > Dubious, test returned 255 (wstat 65280, 0xff00) > Failed 189/262 subtests > [...] > Test Summary Report > --- > t/200-file/400-basic.t(Wstat: 65280 Tests: 73 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 262 tests but ran 73. > Files=65, Tests=4481, 33 wallclock secs ( 0.75 usr 0.21 sys + 14.70 cusr > 1.56 csys = 17.22 CPU) > Result: FAIL This test script doesn't handle errors very well - I largely rewrote it for 1.005 to fix that. Both Imager 1.004 and 1.005 pass for me with stock giflib 5.1.4 on amd64 (but I'm running Debian stable) Tony
Bug#812093: libimager-perl: FTBFS: Failed 1/65 test programs. 0/4481 subtests failed.
On Thu, Jan 21, 2016 at 07:11:01PM +0200, Niko Tyni wrote: > Control: retitle -1 libgif7: DGifOpen() broken because it uses unallocated > memory uninitialized memory, not unallocated. Tony
Bug#812093: libimager-perl: FTBFS: Failed 1/65 test programs. 0/4481 subtests failed.
On Wed, Jan 20, 2016 at 10:38:27PM +0200, Niko Tyni wrote: > On Wed, Jan 20, 2016 at 02:42:04PM +0100, Chris Lamb wrote: > > Source: libimager-perl > > Version: 1.004+dfsg-1 > > Severity: serious > > Justification: fails to build from source > > User: reproducible-bui...@lists.alioth.debian.org > > Usertags: ftbfs > > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > > libimager-perl fails to build from source in unstable/amd64: > > It broke with src:giflib 5.1.2-0.1 -> 5.1.1-0.2. Don't know > why yet. > > % perl -MImager -e 'Imager->new->read(type => "gif", file => > "GIF/testimg/expected.gif") or die' > > dies with the new giflib but not the old one. > > Cc'ing Matthias Klose as a heads-up, he uploaded 5.1.1-0.2. The read failures are caused by a bug present in both 5.1.1 and 5.1.2, partly fixed in giflib git at commit ef0cb9b4be572262b49fbc26fb2348683f44a517. A similar fix is required to DGifOpen() for Imager's GIF support to work (reliably), reported upstream as https://sourceforge.net/p/giflib/bugs/81/ Without the fix the Private member RunningBits isn't initialized, leaving RunningBits as whatever happened to be in memory at that point, so the check in DGifSetupDecompress() has a large chance of failing with a D_GIF_ERR_READ_FAILED error. Adding the initialization allows Imager to pass its tests. That said, there is a bug in that test script, since its custom ok() doesn't have a prototype, the tests on line 65 and 78 pass when they should fail, leading to the crash on line 79 when it tries to compare uninitialized images. Adding a prototype fixes it, though I'll probably end up tossing the custom code and using Test::More. Tony
Bug#692979: Bug#693003: Bug#693002: libimager-perl: breaks libimager-qrcode-perl
The only way I can see to fix this from my end is to have Imager build a separate libimager.so.ABI[1]. For that to be useful though, I suspect packagers would need to extract that libimager.so.ABI into a new package, which might be too much effort for such a minor package. I had planned to break the ABI again with the thread safety changes coming up, but this issue has me reconsidering that. Tony [1] complicated by support for Win32 builds -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543079: libimager-perl: FTBFS: failed tests
This bug reported against libtiff upstream appears to be the same issue: http://bugzilla.maptools.org/show_bug.cgi?id=2088 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543079: libimager-perl: FTBFS: failed tests
On Sat, Aug 22, 2009 at 06:47:53PM +0200, Lucas Nussbaum wrote:
t/t104ppm.ok
t/t105gif.ok
# Failed test 'reading multiple images from tiff'
# at t/t106tiff.t line 315.
Use of uninitialized value in subroutine entry at t/t106tiff.t line 318.
Use of uninitialized value in subroutine entry at t/t106tiff.t line 318.
im2 is not of type Imager::ImgRaw at t/t106tiff.t line 318.
# Looks like you planned 213 tests but only ran 67.
# Looks like you failed 1 test of 67 run.
# Looks like your test died just after 67.
t/t106tiffdubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 67-213
Failed 147/213 tests, 30.99% okay
t/t107bmp.ok
Hi,
I'm the upstream author.
This appears to be change in behaviour for tifflib and is present in
the original non-Debian sources, eg.
#include tiffio.h
#include stdio.h
int main(void) {
TIFF *tif;
int i, y;
char buf[100] = \0;
tif = TIFFOpen(foo.tif, w);
if (!tif) {
fprintf(stderr, Cannot create file\n);
return 1;
}
for (i = 0; i 2; ++i) {
int bytes_pp;
TIFFSetField(tif, TIFFTAG_IMAGEWIDTH, 20);
TIFFSetField(tif, TIFFTAG_IMAGELENGTH, 20);
TIFFSetField(tif, TIFFTAG_SAMPLESPERPIXEL, 3);
TIFFSetField(tif, TIFFTAG_PLANARCONFIG, PLANARCONFIG_CONTIG);
bytes_pp = TIFFScanlineSize(tif);
for (y = 0; y 20; ++y) {
TIFFWriteScanline(tif, buf, y, 0);
}
TIFFWriteDirectory(tif);
}
TIFFClose(tif);
return 0;
}
gcc -otifdirtest tiffdirtest.c -ltiff
./tiffdirtest
tiffdump foo.tif | grep StripByteCounts
# Etch:
StripByteCounts (279) LONG (4) 1160
StripByteCounts (279) LONG (4) 1160
# Sid:
StripByteCounts (279) LONG (4) 10
StripByteCounts (279) LONG (4) 10
# original libtiff 3.9.0
(using LD_LIBRARY_PATH=/home/tony/local/tiff/lib ./tiffdirtest with tiffdirtest
builting against an installed tifflib 3.9.0):
StripByteCounts (279) LONG (4) 10
StripByteCounts (279) LONG (4) 10
From the Imager side of things, the single image function *doesn't*
produce the problem StripByteOffsets - and the only real difference
between that and the multiple image writer is the call to
TIFFWriteDirectory for each image in the multi-image code.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#370651: Check it
steinberg wavelab 5.01a - 49 coreldraw graphics suite 12 - 49 Type 'softnuhere. com' in your |E (w/o spaces and quotes) steinberg cubase sx 2.2.0.33 - 39 alias motionbuilder 6.0 - 49 parallels desktop 3.0 for mac - 29 alias motionbuilder 6.0 - 49 crystal reports professional edition 11 - 69 cakewalk project 5 - 59 microsoft visual studio 2005 professional edition - 149 realize voice 3.51 - 29 discreet combustion 4.0 for windows - 69 adobe creative suite 3 master collection for win - 299 Save up to 74-91%! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421582: libimager-perl 0.58 is now in incoming
Hi Jay, On Thu, May 24, 2007 at 02:27:35AM -0400, Jay Bonci wrote: Hey Tony, Two things, I noticed the other day that you picked up a Sourceforge project for libimager-perl (sf.net/projects/imager-perl). I know these things because I approved the request :) Are you going to be moving development there, or just using that as a backup? For now it's just a backup. Secondly, does the update need to be applied to the stable release? If so, I can begin that process. Please let me know. It needs to applied to stable and oldstable too. Tony -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421582: CVE 2007-2413 or CVE 2007-2459
It looks like both CVE 2007-2413 and CVE 2007-2459 have been assigned to this. The description in 2459 is inaccurate - there was certainly a bug in read_4bit_bmp(), but it could not be used to cause a buffer overflow - or none that I could see. -- Tony Imager maintainer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421582: libimager-perl: buffer overflow when reading 8-bit compressed BMP files
Package: libimager-perl
Version: 0.50-1
Severity: grave
Tags: security patch
Justification: user security hole
I'm the upstream maintainer for the Imager perl module.
The BMP reader in Imager 0.56 and earlier can cause a memory overflow
in a malloced() buffer when reading an 8-bit/pixel compressed image
where a literal or RLE run overflows the scan-line boundary.
This typically causes the program to exit with a glibc bug, but it may
also be possible to corrupt the memory arena in such a way as to
execute arbitrary code, though I don't see how. At the very least
this could be a denial of service.
I've attached a patch that should apply to Imager 0.45 through 0.56
(with some fuzz).
I've released Imager 0.57 to CPAN which fixes this issue.
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages libimager-perl depends on:
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libfreetype6 2.2.1-5FreeType 2 font engine, shared lib
ii libjpeg62 6b-13 The Independent JPEG Group's JPEG
ii libpng12-01.2.15~beta5-1 PNG library - runtime
ii libt1-5 5.1.0-2Type 1 font rasterizer library - r
ii libtiff4 3.8.2-7Tag Image File Format (TIFF) libra
ii libungif4g4.1.4-4shared library for GIF images
ii perl 5.8.8-7Larry Wall's Practical Extraction
ii perl-base [perlapi-5.8.8] 5.8.8-7The Pathologically Eclectic Rubbis
ii zlib1g1:1.2.3-13 compression library - runtime
libimager-perl recommends no packages.
-- no debconf information
Index: bmp.c
===
--- bmp.c (revision 1210)
+++ bmp.c (working copy)
@@ -916,6 +916,13 @@
}
}
else if (packed[0]) {
+ if (x + packed[0] xsize) {
+ /* this file is corrupt */
+ myfree(line);
+ i_push_error(0, invalid data during decompression);
+ i_img_destroy(im);
+ return NULL;
+ }
line[0] = packed[1] 4;
line[1] = packed[1] 0x0F;
for (i = 0; i packed[0]; i += 2) {
@@ -958,6 +965,13 @@
default:
count = packed[1];
+ if (x + count xsize) {
+ /* this file is corrupt */
+ myfree(line);
+ i_push_error(0, invalid data during decompression);
+ i_img_destroy(im);
+ return NULL;
+ }
size = (count + 1) / 2;
read_size = (size+1) / 2 * 2;
if (ig-readcb(ig, packed, read_size) != read_size) {
@@ -1113,6 +1127,13 @@
}
}
if (packed[0]) {
+ if (x + packed[0] xsize) {
+ /* this file isn't incomplete, it's corrupt */
+ myfree(line);
+ i_push_error(0, invalid data during decompression);
+ i_img_destroy(im);
+ return NULL;
+ }
memset(line, packed[1], packed[0]);
i_ppal(im, x, x+packed[0], y, line);
x += packed[0];
@@ -1147,6 +1168,14 @@
default:
count = packed[1];
+ if (x + count xsize) {
+ /* runs shouldn't cross a line boundary */
+ /* this file isn't incomplete, it's corrupt */
+ myfree(line);
+ i_push_error(0, invalid data during decompression);
+ i_img_destroy(im);
+ return NULL;
+ }
read_size = (count+1) / 2 * 2;
if (ig-readcb(ig, line, read_size) != read_size) {
myfree(line);
Bug#359661: libimager-perl: 4 channel JPEGs can crash Imager when writing to a scalar
Here's a simpler example that reproduces the problem:
# 2 or 4 channels, it doesn't matter
my $im = Imager-new(xsize = 1, ysize = 1, channels = 4);
my $data;
# this should fail, but it shouldn't seg fault
$im-write(data = \$data, type = 'jpeg') or die $im-errstr;
The same problem occurs with 2 channel images written to TGA format
streams:
my $im = Imager-new(xsize = 1, ysize = 1, channels = 2);
my $data;
# this should fail, but it shouldn't seg fault
$im-write(data = \$data, type = 'tga') or die $im-errstr;
This problem has existed since at least Imager 0.41.
I'll be releasing Imager 0.50 shortly with a fix for this and 2 other
minor problems in 0.49.
I've attached a patch vs Imager 0.44 if you're looking at an update
for stable.
My dev tree already had a different fix for this problem, since
io_glue_commit_types() had become a no-op.
Tony Cook
Imager maintainer
diff -ru Imager-0.44/jpeg.c Imager-0.44-new/jpeg.c
--- Imager-0.44/jpeg.c 2004-12-02 15:08:10.0 +1100
+++ Imager-0.44-new/jpeg.c 2006-03-28 10:55:33.0 +1000
@@ -413,6 +413,7 @@
mm_log((1,i_writejpeg(im %p, ig %p, qfactor %d)\n, im, ig, qfactor));
i_clear_error();
+ io_glue_commit_types(ig);
if (!(im-channels==1 || im-channels==3)) {
i_push_error(0, only 1 or 3 channels images can be saved as JPEG);
@@ -433,7 +434,6 @@
return 0;
}
- io_glue_commit_types(ig);
jpeg_wiol_dest(cinfo, ig);
cinfo.image_width = im - xsize;/* image width and height, in pixels */
diff -ru Imager-0.44/tga.c Imager-0.44-new/tga.c
--- Imager-0.44/tga.c 2004-12-02 15:08:10.0 +1100
+++ Imager-0.44-new/tga.c 2006-03-29 09:09:47.0 +1000
@@ -810,6 +810,7 @@
mm_log((1, channels %d\n, img-channels));
i_clear_error();
+ io_glue_commit_types(ig);
switch (img-channels) {
case 1:
@@ -834,7 +835,6 @@
return 0;
}
- io_glue_commit_types(ig);
header.idlength;
header.idlength = idlen;
Bug#288272: Very slow on Toshiba Portege 7200
On Mon, Jan 17, 2005 at 03:33:28PM +0900, Horms wrote: If you have a moment could you please check to see if these packages, which will form the basis of 2.4.27-8, resolve your problem. http://debian.vergenet.net/testing/ This solved the speed problem for me too. Thank you Tony -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
