Bugzilla Bug 130889

we're distribute the jpeg library without a feature it calls `maxmem`, which is
used to restrict images from allocating ridiculous amounts of memory and
allowing developers to specify a reasonable limit for allocation.

The documentation all assumes this feature is enabled, and documents settings
suc as the JPEGMEM environment variable, max_mem_to_use jpeg option, the
-maxmemory argument to djpeg and so on. A user might reasonably expect these
setttings to prevent a malicious image from disrupting any image processing
routines that accept images from users, however they do nothing, potentially
resulting in a dos via memory exhaustion.

Suggest adding --enable-maxmem option to configure, which will solve this
problem.

Created an attachment (id=85214) [edit]
example image

graphics herd: please provide an updated ebuild, or comment if appropriate.

what exactly would you say a reasonable limit is ?

How about we replace jpeg_mem_init() in jmemansi.c with a routine that that
uses sysconf() with _SC_PHYS_PAGES? 

example:

GLOBAL(long)
jpeg_mem_init (j_common_ptr cinfo)
{
    long phys_size;

    if ((phys_size = sysconf(_SC_PHYS_PAGES)) == -1)
        return DEFAULT_MAX_MEM; /* defined by libjpeg via --enable-maxmem=xx */
    if ((phys_size *= sysconf(_SC_PAGESIZE)) < 0)
        return DEFAULT_MAX_MEM;
    return phys_size;
}

and set DEFAULT_MAX_MEM to 64M or similar as a fallback? This would be a
reasonable default, but allow JPEGMEM and max_memory_to_use to be honoured by
users who want to prevent memory exhaustion.

Created an attachment (id=85252) [edit]
jpeg-sysconf-maxmem.diff

suggested patch, tested with --enable-maxmem=64 (only used as a fallback)

Created an attachment (id=85260) [edit]
sysconf maxmem patch

the comments in jmemansi.c say "If you can actually get the available space,
it's a good idea to subtract a slop factor of 5% or so.", so this patch does
that.

Misplaced

graphics team please patch

I had to drop ~x86-fbsd keyword from -r7 because the calls are very linux
specific, I do have a portable patch, if that can be used instead of the
current would be perfect.

Created an attachment (id=87770) [edit]
Updated patch supporting FreeBSD and DragonFly and with fallback.

arches please test and mark 6b-r7 stable, thanks

alpha stable.

Darwin has a problem similar to BSD.  However, Diego's patch won't work for us.
 I need something like this:

#if HAVE_SYSCTL && defined HW_PHYSMEM
  { /* This works on *bsd and darwin.  */
    unsigned int physmem;
    size_t len = sizeof physmem;
    static int mib[2] = { CTL_HW, HW_PHYSMEM };

    if (sysctl (mib, ARRAY_SIZE (mib), &physmem, &len, NULL, 0) == 0
        && len == sizeof (physmem))
      return (double) physmem;
  }
#endif

Diego, is your patch yet in (doesn't look like so), and can above code be
combined with yours?  I grabbed above thing from
http://www.opensource.apple.com/darwinsource/WWDC2004/gccfast-1614/libiberty/physmem.c

I cannot mark this package stable on ppc-macos because the package doesn't
compile.

sparc stable.

Created an attachment (id=88017) [edit]
Updated patch supporting *BSD and Darwin and with fallback.

Here it is, thanks Fabian :)

Created an attachment (id=88028) [edit]
Re-Updated patch supporting *BSD and Darwin and with fallback.

this patch fixes the return type to be long, and to return 0 in case the
condition does not hold.

stable on ppc64

(From update of attachment 88028 [edit])
this patch is wrong.  Don't use it.  Sorry for the spam.

Created an attachment (id=88029) [edit]
latest darwin/bsd/linux maxmem patch from SVN by Flameeyes

Attached is the proper fix for BSD/Darwin and GNU/Linux.  This patch should be
put in the patch file after which I can mark ppc-macos stable.

Taviso or who is responsible: could you add + patchrevbump this patch to the
current ebuild?  Thanks.

amd64 stable.

on x86:

compiles fine. Further I ran several transformations on an image which also
went fine and gave the expected result. I also tested the functionality of the
library itself by using KDE and Gimp which worked fine as well.

ppc stable

x86 done, thanks for testing Sander

Stable on hppa

*** Bug 135644 has been marked as a duplicate of this bug. ***

Calling a GLSA vote on this one:

<taviso> re jpeg, i dont think glsa is nescessary, it's very lame...just a
client dos

Does any important applications use this?

(In reply to comment #26)
> Does any important applications use this?

Many applications do. Here is a list of some popular apps that use it: emacs,
wine, abiword, ghostscript-*, php, blender, gimp, gphoto2, cups,
mozilla{-firefox}, qt, opera, and others.

Complete List: http://gentoo-portage.com/media-libs/jpeg/RDep#ptabs

Ok lets have the GLSA.

yes, as for me a GLSA is needed, since this issue allows me to crash nearly
every computer of my friends :), whatever they use (konq, firefox, safari,
IE...).  Some other linux distributions, and MacOS, windows... are affected
too.

GLSA 200606-11

arm, bsd, ia64, mips, ppc-macos, s390, sh don't forget to mark stable to
benifit from the GLSA.

Did _anybody_ take into consideration my and Grobian's messages?

Both Gentoo/*BSD and Gentoo for Mac OSX are cut off by that patch unless
someone apply our version, that's a no-op for anyone else.

If nobody from the interested parts is going to make that change in 24h, I
suppose either me or Grobian will do that, but consider that anybody wanting to
scream at us afterward will have had enough time to validate and comment.

Sorry Diego I thought that it had already been applied. Taviso who applied the
initial patch has been mostly away for some weeks due to a job change. (no
screaming from here)

Diego, as I'll not be able to do this and mark ppc-macos today/tonight (no
access to my machine), can you do this if you have time?  Please also set the
proper ppc-macos keyword if you do, I already tested with your patch.  Thanks.

I updated the patchset to include Darwin/BSD fixes.  Marked ppc-macos stable. 
Flameeyes can you manage the overlay (to which I committed the last cleaned up
and working version of the patch) in the way you like?  (e.g. removing or
whatever, the patch is now in the main tree)

6b-r7 stable on mips.