Kernel prepatch 6.5-rc4: Documentation patches

"Documentation: security-bugs.rst: update preferences when dealing with the linux-distros group" (https://git.kernel.org/linus/4fee0915e6) essentially says, preferably do not contact linux-distros@ at all, and if you must contact them, do so after a fix has been worked out with security@kernel.org. The distros list mandates vulnerability disclosure in certain ways when you post to the list, which seems like it's an unpopular rule. See also the previous LWN discussion at https://lwn.net/Articles/927667/ - I'm sympathetic to the distros list trying to do something to both coordinate embargoes and require timely disclosure, but this seems like a pretty big sign that the current thing they're doing isn't working right.

"Documentation: security-bugs.rst: clarify CVE handling" (https://git.kernel.org/linus/3c1897ae4b) makes it clear that the kernel will not assign you a CVE nor wait for a CVE. In the mailing list discussion, Greg says, "I can not, in good faith, with the current mess that MITRE is going through, tell anyone that they should contact MITRE ahead of public disclosure, sorry" - an issue that has been plaguing the CVE process for years, and I'm sad that it hasn't gotten better - and "many non-US-based companies are not allowed to contact a US-government-backed entity for potential security issues for obvious reasons," which I hadn't heard of before but makes some amount of sense. From https://www.cve.org/ProgramOrganization/CNAs it looks like while there are CNAs in Russia and China, all but one of them, Kaspersky, only assigns CVEs for their own products.

(On a side note, if anyone from the US government wants to enhance cybersecurity and protect freedom, figure out how to fix the CVE process!)

"Documentation: embargoed-hardware-issues.rst: clean out empty and unused entries" (https://git.kernel.org/linus/28f47693a9) removes the AMD contact, but "Documentation: embargoed-hardware-issues.rst: add AMD to the list" (https://git.kernel.org/linus/645bb6b1fe0) adds it back in. There's no public explanation of what happened, but given the timing, my guess is it relates to how Zenbleed was handled.