Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 15 Jun 2017 10:14:38 -0700
From: Feng Cao <>
CC: Kurt Seifried <>
Subject: Re: Re: MySQL - use-after-free after mysql_stmt_close()

There are several issues which need to be addressed before considering
CVE for documentation. First, most of the documentations have no version
control. Second, CPE doesn't have such a category. Third, it can easily
generate the confusion with CVE for the code fix.

My vote is no.



On 6/15/2017 7:21 AM, Kurt Seifried wrote:
> This does bring up an old question:
> Should we assign CVEs for code examples/documentation? E.g. We assign CVEs
> for code shipped to people in digital form. Why not assign CVEs for code in
> documentation or commonly used examples? We can go with the rational that
> CVEs get assigned to the affected code bases (e.g. when someone implements
> that documentation/code), but it might also be good to educate the
> community about bad examples/documentation/etc.
> My thinking is:
> 1) Official documentation that says "do this [insecure thing]" should
> probably get a CVE (e.g. "turn off all the encryption to make it work more
> easily"). This should probably get a CVE, especially as it results in
> operational changes which won't get a CVE (since it's not in code that
> "ships", it's just on the end of whoever is using it).
> 2) Official code examples, as above, actual implementations get CVEs, it
> might be useful to raise awareness that the example is bad.
> 3) Unofficial but commonly used documentation and code examples, I guess
> the best example here is stackoverflow and friends?
> Thoughts/comments (feel free to reply privately if you don't want to be
> public)? I'd like to collect what people think and then present it to the
> CVE board later (this has been on my long term todo list).
> On Thu, Jun 15, 2017 at 7:50 AM, Adam Maris <> wrote:
>> On Mon, 2017-06-12 at 23:47 +0200, Pali Rohár wrote:
>>> Hello!
>>> Any idea how to handle this particular problem?
>> Hi!
>> Given that Oracle (silently) updated the vulnerable example in their
>> documentation, this likely indicates the way to handle this -
>> applications that copied the vulnerable example needs to be fixed and
>> CVEs will be assigned per application.
>> Best Regards,
>> --
>> Adam Mariš, Red Hat Product Security
>> 1CCD 3446 0529 81E3 86AF  2D4C 4869 76E7 BEF0 6BC2

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.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ