Is there a documented process for official information release for embargoed vulnerabilities in the CVE system?

Question

Is there a documented process for official information release for embargoed vulnerabilities in the Common Vulnerabilities and Exposures (CVE) system?

If such a process exists, how does it address situations like the recent Intel Kernel page-table vulnerability, where the vulnerability has already been publicly disclosed via unofficial channels, and a publicly available proof-of-concept exploit has already been documented?

I have been attempting to estimate the impact of the recent, embargoed Intel Kernel page-table vulnerability mentioned in this question. As mentioned in that post, this vulnerability has numerous references in social media accounts dating back to November 4th, forums, many news sites, and the Linux patches (December 4th) have even been benchmarked. There is even a Wikipedia article about it, as well as public documentation dating back up to 6 months. The lack of official information regarding this vulnerability and the intense public scrutiny of the hardware flaw and pending software workaround have led to a large amount of conflicting information being published.

With all of this unofficial information available, I have not yet encountered a single identifier associated with the vulnerability that provides a common reference for the patches and discussions. We know there is a CVE number, but since it is embargoed, neither the number nor any official documentation has been released to the public. Linux updates containing patches for this vulnerability will be released by Amazon as soon as January 5th and a similar one by Microsoft is expected by January 9th, yet there is zero official information available, which will result in these updates being deployed by many organizations (including mine) based only on wildly conflicting information regarding the cause while incurring an estimated 30% performance hit to multiple layers of many software stacks.

I understand the idea behind the embargo - disclosing too much information before a fix or workaround is available will give a head start to individuals or organizations writing exploits. However, the amount of unofficial information already available seems to have made the embargo a moot point, considering there are already proof-of-concept exploits documented.

Answer 1

The Google disclosure(s) yesterday evening (January 3rd) contains a concise summary of the end of the embargo, which was originally planned for January 9th, but was moved forward one week due to the amount of public information already available.

From "Reading privileged memory with a side-channel":

We [Google] reported this issue to Intel, AMD and ARM on 2017-06-01.

From "Today's CPU vulnerability: what you need to know":

We are posting before an originally coordinated disclosure date of January 9, 2018 because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation. The full Project Zero report is forthcoming (update: this has been published; see above).

The CVE identifiers and disclosures were made publicly available as soon as the embargo ended:

Meltdown Attack

Mitre CVE-2017-5754 and NIST NVD CVE-2017-5754

Spectre Attack

Mitre CVE-2017-5753 and NIST NVD CVE-2017-5753

Mitre CVE-2017-5715 and NIST NVD CVE-2017-5715

The CVE identifiers were made public with the end of the embargo, which served as placeholders in the CVE and NVD databases for several hours. As of January 4th, the disclosure was publicly available via those sites.