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():
>
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
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
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
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
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 #
>
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
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
>
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
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
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
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
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
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,
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
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
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
17 matches
Mail list logo
