[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 3 Jun 2015 01:44:57 -0400 (EDT)
From: cve-assign@...re.org
To: wmealing@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE request: vulnerability in the kernel tty subsystem.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> a new tty thread could hold a reference to the ldisc lock used during
> the shutdown phase in the original thread and create a deadlock.
> This section of code was re-written upstream by creating a read/write semaphore to
> specially to handle ldisc, ldsem ( 4898e640caf03fdbaf2122d5a33949bf3e4a5b34 ).
>
> No root permissions are required to recreate the deadlock.
Use CVE-2015-4170.
We realize that there was debate about whether it is right to assign
a CVE ID. Here's a comment on that. (The rest of this message doesn't
have any discussion of this old kernel vulnerability itself.)
> From: Greg KH <greg@...ah.com>
> Date: Fri, 29 May 2015 15:04:30 -0700
>
> And that's it, it's not a "we need to track this", for such old bugs
> (and by "old" I would classify anything older than a year for the kernel
> as old, as that's hundreds of thousands of patches ago)? It's the job
> of companies that insist on using such old software, to maintain and
> keep them up to date, it's not the job of the "community" here to have
> to deal with assigning issues to things that are really old and already
> fixed.
Our perspective is that there are (at least) three different issues
related to oss-security messages about a fixed-two-years-ago bug.
1. Possibly the bug should not be discussed here because too few
people are interested. If the list rules were changed from
"Public security issues only" to something like "Recent public
security issues only," then we would follow the new rules. We
haven't announced a preference for whether there should be a
change. Also, everyone already has the option to self-select,
e.g., if a person thinks their security issue is less interesting
because it's two years old, they could choose to send their CVE
request only to MITRE directly. There are no cases in which we
require anyone to send any request to oss-security.
2. Possibly a CVE ID should not be sent here because that, in
effect, means everyone receives twice as many messages about
fixed-two-years-ago bugs. It's conceivable that MITRE could make
it easier for people to filter out these messages, e.g., if we
added something in the header whenever a message from us was only
about an ID number and wasn't an attempt to contribute to
discussing a vulnerability.
3. Possibly a new CVE ID should not exist at all for a
fixed-two-years-ago bug. This is a type of change that MITRE
conceivably might want to make in the future. Right now, however,
we haven't ever announced that a CVE request has to be within N
months or years of a bug fix or disclosure, and we're not going
to be changing that abruptly. More specifically, we're not going
to abruptly drop support for an existing use case in which
companies who ship older kernels can have CVEs for older issues.
This doesn't mean that we can add new support for all possible
alternative use cases, e.g., bulk requests for every current bug.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJVbpMzAAoJEKllVAevmvmswBQH/RxV3BFEJ0kphtIB2SMHjzYT
SpPGqfbooC7ng+aZcEUqVGrun7dbU2qHgBZMAjPDW2GNO3qukJvfNebpel8ERtS+
Y7AT/SUdNFekbKotHKT1lave9NxuGalLCxLM/Ed702M3ldwe865tIx3CPaPkYgHu
vxI3Os1FSwkV1QT7zaO8KZF1vyW6rsDKfub+erg3j/pAMyb1h1J+SZpfP5EZIsKR
eeDFfjtdTcCwbS21Z4ND5Qlk48l1o81rZvQIhhVnaYnA6K31Pk7zT9S3t5Isa4D2
DTaheht2VEXOZMDAw0jZaot5GHYp7V3Rxe/pl/Ke71Tu1fYEW7RMQiPqHDS172s=
=r/3a
-----END PGP SIGNATURE-----
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.
