Apologies to all for the long post, but this discussion might significantly impact how CVE assignment occurs in the future, and I intend to reference it heavily. We (MITRE CVE) specifically request feedback from members of the various Linux distributions on this list, since they will be affected most directly, although input from anybody is welcome. In the "Linux kernel: various info leaks, some NULL ptr derefs" thread, Petr Matousek said: In the past we've usually assigned one CVE per issue even for info leak bugs. Or at least one CVE per subsystem, as Alexander says. I agree with Alexander that one CVE for about ~20 issues is not right. Established CVE practice does not dictate assigning a separate ID for each bug. While this is useful for some people, it's not useful for others, and many times this information is not even available - or it can change over time. Although it often looks like one CVE is assigned per issue, that is by accident, and there are other drivers that decide how many CVEs should be assigned. More explanation later in this post. The "spirit" of CVE content decisions is documented here: http://cve.mitre.org/cve/editorial_policies/cd_abstraction.html In the first couple years of CVE, we tried to assign unique IDs for each vulnerability, but there was too much inconsistency and too much uncertainty. In many cases, we simply did not have enough data to know how many vulnerabilities there even were. Or, we might choose to assign "X" number of IDs to a multi-issue disclosure, and then 2 weeks later, more details would come out that would really suggest needing a different number of IDs than we had originally assigned. You see this kind of "counting uncertainty" on oss-security on a regular basis, even today. So, CVE needs to operate in a space where the amount of detail varies widely. CVE also needs to be usable to many communities with different needs. Its primary role is to help these communities to coordinate vulnerability information with each other - that is, CVE acts as a "coordination ID." Different vulnerability-information consumers operate at different levels of abstraction. For example, many system administrators don't necessarily care about individual kernel bugs, but they might care much more about a single patch action as implied by a single vendor advisory that updates to a new kernel version; these admins may operate on the "advisory ID" level of abstraction. On the opposite end of the spectrum is the open source community, which has effectively started using CVE as a "universal bug ID" - that is, they operate at the "bug ID" level of abstraction. This is useful for coordination between distro maintainers, but not for coordination with other communities that CVE serves. With respect to the number of IDs that get assigned to a disclosure of one or more bugs/vulnerabilities, CVE's abstraction has evolved to be somewhere in between that of the vendor ID and the bug ID. Since CVE's primary role is to support coordination across many communities who operate at different levels of abstraction, being "in the middle" maximizes CVE's utility to all of these communities - but it also means that it is rarely a perfect match for each individual community. For CVE, we knowingly combine multiple vulnerabilities into the same ID, if they (1) are the same vulnerability type, (2) affect the same code versions, and (3) were disclosed at the same time by the same person/organization. (Note that this is a simplification.) We have found that these details are usually available in disclosures, they are provided very early in the disclosure process, and they don't often change significantly over time. With these guidelines, it is easier for different people to consistently assign the same number of CVE IDs. The system is not perfect, and CVE Numbering Authorities (CNAs) don't always follow these guidelines, but it works pretty well to keep CVEs usable as coordination IDs. Whatever decision MITRE makes on how to go forward, we will be following the spirit of these well-established practices. I know this conflicts with the open source community's need for a "universal bug ID," and that's why I'm suggesting the creation of a separate bug ID system, perhaps centered around a scheme such as a commit ID/hash (which is often used already, such as in the original CVE request that prompted this message). There is still a question about how CVE can reasonably handle disclosures of multiple issues for the Linux kernel and other complex, large software that is heavily reused and adapted. Such code may be maintained by a single upstream developer, but as we all know, each distribution has its own practices and maintains its own versions. For the Linux kernel, this is a special challenge. Let's take Kurt's assignment of CVE-2012-6138 for the kernel info-leak issues discovered by Mathias Krause. Mathias said that he did not investigate these too closely, which is completely understandable - yet now we have some very raw, detailed, public information that is not necessarily expressed in ways that help CVE to make appropriate decisions about the number of IDs to assign. With respect to CVE's practice of "SPLIT by vuln type," while the issues are all information leaks, note that an "information leak" is a *consequence* of a bug, not an actual *type* of bug. There are many different bug types that can lead to the disclosure of potentially-sensitive information. The issues reported by Mathias appear to contain problems like out-of-bounds reads and improperly-uninitialized data, so a closer investigation would likely produce a SPLIT. With respect to CVE's practice of "SPLIT by version," we don't know for sure which bugs affect which versions. We know when the bugs got fixed, but not necessarily when they were introduced - it's too early in the disclosure. And the distributions are likely to handle these groups of bugs differently, so even if they are fixed in the same upstream kernel version, there are likely to be variations in which issues are fixed by each distro in their "local" (downstream) kernel versions. While it would be convenient to assume that each bug might affect some slightly different version in at least one distro, assigning a unique CVE ID for each bug would increase the volume of CVEs to a point where it hurts the usability of CVE to other consumers outside the distro-maintenance community. Solar Designer's suggestion of per-subsystem SPLITs is an intriguing, approximate solution to CVE's "version" problem in widely-shared code like the Linux kernel. It seems likely that many subsystems are introduced in different upstream kernel versions, and probably updated in different versions. Some subsystems might be enabled or disabled by sysadmins. By using the directory structure of the source code tree, subsystems might be reasonably inferred on a consistent basis. It is by no means perfect, but it should be fairly repeatable. Considering the Krause kernel info-leaks as an example, this might suggest about 11 CVEs for crypto, xfrm_user, net (including net/tun), ipvs, dccp, llc, l2tp, Bluetooth, atm, udf, and isofs. There might be additional SPLITs based on bug type. What do people think? To the distro maintainers: given that CVE cannot support per-bug IDs for the reasons I've already described, are per-subsystem SPLITs workable? - Steve & the CVE-Assign Team