Re: Re: Linux kernel: more net info leak fixes for v3.9

[Petr Matousek <pmatouse () redhat com>]

On Mon, Apr 22, 2013 at 11:02:10AM -0700, Greg KH wrote:
> On Mon, Apr 22, 2013 at 01:43:17PM -0400, cve-assign () mitre org wrote:
> > > On Mon, Apr 22, 2013 at 01:44:17AM -0400, cve-assign () mitre org wrote:
> > > > 680d04e0ba7e926233e3b9cee59125ce181f66ba CVE-2013-3236
> > > > d5e0d0f607a7a029c6563a0470d88255c89a8d11 CVE-2013-3237
> > >
> > > Please explain how these can get a CVE number when the code involved has
> > > never even been in a kernel.org release yet?
> >
> > MITRE has never had any restrictions on CVEs for issues that exist
> > only in release-candidate software or only in beta software. See for
> > example "Attendees agreed that CVE should include problems in beta
> > software, provided that the beta code was intended for public
> > dissemination" in the
> > http://cve.mitre.org/data/board/archives/2000-03/msg00007.html post.
> >
> > These CVEs tend to be rare, possibly because they are useful to fewer
> > people. Recent examples in which a major vendor specifically chose to
> > assign a CVE name to an issue affecting only beta software are:
> >
> >   CVE-2009-2968 - VMware Studio 2.0 public beta
> >
> >   CVE-2010-0113 - Symantec Norton Mobile Security 1.0 Beta
> >
> > A few months ago, MITRE started to draft some rough guidelines for a
> > case of a vendor who was considering use of CVEs during beta testing.
> > That case seems mostly inapplicable to the current question
> > (CVE-2013-3236, CVE-2013-3237, etc. weren't in any sense based on
> > "vendor" requests), but we might be able to share guidelines at some
> > point if any vendor here is in a similar position.
>
> Thanks for the explanation, but, given the rate-of-churn[1] in the Linux
> kernel -rc releases, I would be really wary to start wanting to assign
> CVEs to things that only show up in these types of kernel releases.
>
> Unless you really want to be swamped with requests, it's your choice :)
>
> Linux kernel -rc releases are for developers, and for those people
> wanting to help with Linux kernel development, they are not for anyone
> to run on any system that they do not to expect to immediately explode
> into a bunch of pieces, let alone expect to be "perfect" from a security
> standpoint.

I agree with Greg. We (Red Hat) haven't requested CVEs for issues in -rc
releases, which we consider under development, in the past and we do not
intend to start doing that. It's in fact one of the criteria when
examining upstream commits - if the bug and the fix is in -rc release,
skip it.

Just my 2 cents.

-- 
Petr Matousek / Red Hat Security Response Team