Frank K=FCster [2005-12-08 13:17 +0100]:
> Martin Pitt <email address hidden> wrote:
>=20
> > Hi!
> >
> > I'm currently preparing Ubuntu security updates for these issues, and
> > I noticed that the upstream provided patch is wrong. I sent the mail
> > below to upstream (and some others).
> >
> > Can you please check that you indeed fixed (tetex-bin)/will fix
> > (poppler) DCTStream::readProgressiveSOF(), too?
> [...]
> > It seems that the patch linked from these advisories [1] is a little
> > bit flawed: it checks numComps twice in DCTStream::readBaselineSOF(),
> > but does not check it in DCTStream::readProgressiveSOF().
>=20
> We have the same flaw in our upload. Would you be so kind and check the
> updated patch at=20
>=20
> http://svn.debian.org/wsvn/pkg-tetex/tetex-bin/trunk/debian/patches/patch=
-CVE-2005-3191+2+3?op=3Dfile&rev=3D0&sc=3D0
The DCTStream::readProgressiveSOF() seems to be correct now, however,
there is still a flaw in=20
Message-ID: <email address hidden> 1?Q?K=FCster? = <email address hidden>
Date: Thu, 8 Dec 2005 14:33:50 +0100
From: Martin Pitt <email address hidden>
To: Frank =?iso-8859-
Cc: Martin Pitt <email address hidden>, <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?
--XsQoSWH+UP9D9v3l Disposition: inline Transfer- Encoding: quoted-printable
Content-Type: text/plain; charset=iso-8859-1
Content-
Content-
Hi Frank!
Frank K=FCster [2005-12-08 13:17 +0100]: :readProgressiv eSOF(), too? :readBaselineSO F(), :readProgressiv eSOF(). svn.debian. org/wsvn/ pkg-tetex/ tetex-bin/ trunk/debian/ patches/ patch= 3191+2+ 3?op=3Dfile& rev=3D0& sc=3D0
> Martin Pitt <email address hidden> wrote:
>=20
> > Hi!
> >
> > I'm currently preparing Ubuntu security updates for these issues, and
> > I noticed that the upstream provided patch is wrong. I sent the mail
> > below to upstream (and some others).
> >
> > Can you please check that you indeed fixed (tetex-bin)/will fix
> > (poppler) DCTStream:
> [...]
> > It seems that the patch linked from these advisories [1] is a little
> > bit flawed: it checks numComps twice in DCTStream:
> > but does not check it in DCTStream:
>=20
> We have the same flaw in our upload. Would you be so kind and check the
> updated patch at=20
>=20
> http://
-CVE-2005-
The DCTStream: :readProgressiv eSOF() seems to be correct now, however,
there is still a flaw in=20
- img.tiles =3D (JPXTile *)gmalloc( img.nXTiles * img.nYTiles *
- sizeof(JPXTile));
+ nTiles =3D img.nXTiles * img.nYTiles;
+ // check for overflow before allocating memory
+ if (nTiles =3D=3D 0 || nTiles / img.nXTiles !=3D img.nYTiles) {
+ error(getPos(), "Bad tile count in JPX SIZ marker segment");
+ return gFalse;
+ }
+ img.tiles =3D (JPXTile *)gmalloc(nTiles * sizeof(JPXTile));
gmalloc does a multiplication which is not checked for integer
overflows. xpdf uses gmallocn() which does that check.
I'll send you an updated patch very soon, I just finished patching
tetex-bin 2.0.2, cupsys, xpdf, poppler, etc.
Martin
--=20 www.piware. de www.ubuntu. com www.debian. org
Martin Pitt http://
Ubuntu Developer http://
Debian Developer http://
In a world without walls and fences, who needs Windows and Gates?
--XsQoSWH+UP9D9v3l pgp-signature; name="signature .asc" Description: Digital signature Disposition: inline
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
DecnbV4Fd/ IRAtNaAJ9Z3WuPx QvhHVgDw6Kt1+ WHROSDxACg6v1w Vt3mZ+ZY=
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDmDY+
/HHv+Ap9V1siAkO
=ktd+
-----END PGP SIGNATURE-----
--XsQoSWH+ UP9D9v3l- -