Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 25 Oct 2016 12:13:44 -0700
From: Tavis Ormandy <taviso@...gle.com>
To: oss-security@...ts.openwall.com
Cc: ago@...too.org, Assign a CVE Identifier <cve-assign@...re.org>
Subject: Re: Re: jasper: memory allocation failure in
 jas_malloc (jas_malloc.c)

On Sat, Oct 22, 2016 at 6:03 PM,  <cve-assign@...re.org> wrote:
>
>> https://blogs.gentoo.org/ago/2016/10/18/jasper-memory-allocation-failure-in-jas_malloc-jas_malloc-c
>>
>> AddressSanitizer failed to allocate 0x1000002000 bytes of LargeMmapAllocator
>>
>> 0x7f4f0474e170 in jas_malloc ... jasper-1.900.5/src/libjasper/base/jas_malloc.c:117:9
>> 0x7f4f04764b4f in bmp_getinfo ... jasper-1.900.5/src/libjasper/bmp/bmp_dec.c:297:25
>
> Use CVE-2016-8886.
>

I'm not sure I understand the concern here. Isn't it usually expected
that the administrator configures appropriate ulimits, and the code
should just handle allocation failure gracefully?

If we are considering *not* implementing arbitrary hardcoded limits a
security problem, that seems like a significant change in software
design philosophy (I've heard it called the zero-one-infinity rule
before).

Tavis.

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.