Kernel prepatch 6.5-rc4

[Posted July 30, 2023 by corbet]

The 6.5-rc4 kernel prepatch is out for testing.

So here we are, and the 6.5 release cycle continues to look entirely normal.
In fact, it's *so* normal that we have hit on a very particular (and peculiar) pattern with the rc4 releases: we have had *exactly* 328 non-merge commits in rc4 in 6.2, 6.3 and now 6.5. Weird coincidence.
And honestly, that weird numerological coincidence is just about the most interesting thing here.

Kernel prepatch 6.5-rc4: Documentation patches

Posted Jul 30, 2023 22:18 UTC (Sun) by geofft (subscriber, #59789) [Link] (1 responses)

The Documentation patches from Greg K-H are mildly interesting:

"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.

Kernel prepatch 6.5-rc4: Documentation patches

Posted Jul 31, 2023 13:52 UTC (Mon) by Smon (guest, #104795) [Link]

Very interesting, thank you very much for pointing that out!