Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 12 Mar 2015 14:17:27 -0400 (EDT)
Subject: Re: CVE Request: Gtk2 Perl Module: incorrect memory management in Gtk2::Gdk::Display::list_devices

Hash: SHA1

> A new upstream version of the Gtk2 Perl module was released (1.2495)
> fixing incorrect memory management in
> Gtk2::Gdk::Display::list_devices. Upstream commit is at
> References:
> -----------
>  -
>  -
>  -
>  -

In this situation, we didn't immediately reach a conclusion about how
to incorporate the perspective of the upstream vendor. Specifically,
says 'Do you really need such an "official" and elaborate effort for
this kind of bug fix? These kinds of fixes are done all over the place
all the time without special announcements.'

The upstream fix removes a "g_list_free (devices);" with a comment of
"Fix incorrect memory management in
Gtk2::Gdk::Display::list_devices ... We do not own the returned list." says "Did not find
any PoC."

Maybe the initial question is "do all changes of this type, in all
products, always qualify for a CVE ID?"

If, for example, the upstream vendor meant that "all over the place
all the time" fixes are exclusively "fixes for issues that are known
to be non-exploitable, not even for a crash," then we think there
probably should not be a CVE ID. If nobody has any definitive
information about an impact, then the answer is much less clear.
Before assigning a CVE ID, we might (or might not) want to require
further information, such as how is "devices" used after the
g_list_free. A recent academic paper that tries to further categorize
related issues is:

The timeline seems to be:

1. An incorrect g_list_free was found. There's perhaps no information
   about how it was found. It might, for example, have been found
   through an automated testing approach that has the potential of
   discovering thousands of similar code problems.

2. The fix was mentioned in an upstream announcement of a new release.

3. One or more persons in the Linux vendor community noticed the new
   release (possibly because of automated checking for new upstream

4. Because the type of code problem is one that is sometimes (one may
   argue "frequently") exploitable, multiple Linux vendors distributed
   a fix.

5. There doesn't seem to be a reference indicating that any analysis
   of impact was done, or that otherwise tries to establish that this
   specific code issue is best categorized as a vulnerability.

6. Still, there is interest in a CVE ID because Linux vendors often
   have a CVE mapping associated with a code change of this type.

It's unclear to us exactly what should happen here. Should we be using
a "per release" attribute as one aspect of deciding whether a CVE ID
is needed? (Specifically, because this one code change was apparently
the primary motivation for releasing 1.2495, does that increase the
importance of having a CVE ID?) Is it sufficient that everybody agrees
the code was wrong and that nobody has ruled out exploitability? If
someone happens to enumerate the complete set of the "all over the
place all the time" fixes that the upstream vendor mentioned, do they
all need CVE IDs as well?

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


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.