Comment 29 for bug 26650

Message-ID: <email address hidden>
Date: Thu, 08 Dec 2005 22:21:53 +0100
From: Florian Weimer <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Cc: <email address hidden>, Martin Pitt <email address hidden>, Martin Pitt <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

* Frank K=FCster:

> Would=20
>
> if (nTiles >=3D INT_MAX / sizeof(JPXTile) {
> error(getPos(), "Bad tile count in JPX SIZ marker segment");
> return gFalse;
>
> be okay?

It might still be a DoS issue, I think. Allocating arbitrary amounts
of memory upon user request is usually a bad idea. But gmallocn does
not touch the memory it allocates, so even very large allocations are
very cheap initially. As long as you initialize the allocated data
structure as you read more input, it should be a minor issue (because
you need an enormous file size to cause problems on even slightly
dated machines).

By the way, the gmallocn function suffers from undefined integer
overflow, too:

void *gmallocn(int nObjs, int objSize) {
  int n;

  n =3D nObjs * objSize;
  if (objSize =3D=3D 0 || n / objSize !=3D nObjs) {
    fprintf(stderr, "Bogus memory allocation size\n");
    exit(1);
  }
  return gmalloc(n);
}

The error handling is not suitable for library use, either. I don't
know if this is a problem.

PS: I haven't checked if the comparison "nTiles >=3D INT_MAX /
sizeof(JPXTile" is indeed correct and checks the right bound.