Re: Linux 3.4+: arbitrary write with CONFIG_X86_X32 (CVE-2014-0038)

[Solar Designer <solar () openwall com>]

On Fri, Jan 31, 2014 at 06:54:17PM +0100, rf () q-leap de wrote:
> > > > > > "SD" == Solar Designer <solar () openwall com> writes:
>     SD> The "assigned" date seen on CVE IDs often indicates when a pool
>     SD> of CVE IDs was created and then assigned to a CNA (Red Hat in
>     SD> this case), not when individual CVE IDs are assigned to actual
>     SD> issues.  It is perfectly normal (albeit confusing) for the
>     SD> "assigned" date to be earlier than the vulnerability discovery
>     SD> date.  This was discussed in here before:
>
>     SD> http://www.openwall.com/lists/oss-security/2012/01/23/4
>
>     SD> CNAs:
>
>     SD> http://cve.mitre.org/cve/cna.html
>
> Sorry for the repetition,

That's OK.

> but I wasn't subscribed yet at the time

I think you were in fact not subscribed in 2012.

> or is this a FAQ?

This is not a very frequent question, but I've seen this sort of
confusion several times, in different places.  I don't know if it's
addressed in some sort of FAQ list.

I think there's room for improvement for the language used on CVE ID
pages like https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0038 ,
which currently says:

"Date Entry Created
20131203         Disclaimer: The entry creation date may reflect when
the CVE-ID was allocated or reserved, and does not necessarily indicate
when this vulnerability was discovered, shared with the affected vendor,
publicly disclosed, or updated in CVE."

but follows this with:

"Phase (Legacy)
Assigned (20131203)"

I'm not surprised the latter continues to confuse people, as it appears
not to fall under the disclaimer.  I think the disclaimer should be
worded such that it'd clearly apply to "Phase (Legacy) \n Assigned" as
well.  (And even then some confusion will remain, just maybe less of it.)

Alexander