Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 1 Nov 2016 14:18:40 -0400
From: <>
To: <>
CC: <>, <>
Subject: Re: Handful of libass issues

Hash: SHA256

>>> The third is a huge memory allocation leading to a crash that wasn't
>>> fixed because a good solution is unavailable at the moment.


>> Use CVE-2016-7971.

The vendor's comment was:

> grigorig commented Oct 5, 2016
> I don't have a strong opinion about the CVE.

The MITRE CVE team has no current plans to reject this CVE. Someone
may want to use the CVE ID to track something. For example, there may
be people who need to track that libass is not suitable for their own
use case because they require exactly the "the best you can do is to
make sure [rendering] gracefully fails with an appropriate error
report (error code or exception or whatever you use) if memory can't
be allocated or if a library-user-specified limit is exceeded - then
the library user can handle that however they want to, for example by
exiting (appropriate for a command-line tool) or by reporting an error
but continuing to accept new requests (appropriate for a daemon)."
behavior suggested in the post.

Even if neither the upstream vendor nor any Linux distribution will
ever make any code change for CVE-2016-7971, discussion of the issue
can help with understanding the product's behavior. For example,
pull/240 also has a vendor comment of "Normally we should handle
memory allocation failures gracefully, but there's probably still a
lot of code which just crashes" that may be very relevant to planning
other research.

The MITRE CVE team is willing to mark a CVE with "DISPUTED" if someone
believes that it's based solely on an "AddressSanitizer failed to
allocate ... bytes of LargeMmapAllocator" misinterpretation, and
believes that it cannot have any relevance to risk management.

Also, of course, if a finding (such as "AddressSanitizer failed to
allocate ... bytes of LargeMmapAllocator" without follow-on research)
has no known audience, then sending a CVE ID request may not be the
best approach.

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at ]
Version: GnuPG v1


Powered by blists - more mailing lists

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.