On Wed, Feb 14, 2024 at 02:43:48PM +0100, Jiri Kosina wrote: > On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote: > > > +No CVEs will be automatically assigned for unfixed security issues in > > +the Linux kernel; assignment will only automatically happen after a fix > > +is available and applied to a stable kernel tree, and it will be tracked > > +that way by the git commit id of the original fix. > > I think this needs way more clarification .. how exactly is this going to > work? > > Do I read this correctly that *everything* that lands in -stable will > automatically get CVE assigned? If so, that's just plain crazy. Just took > a random peek on the topmost -stable changelog ... > > ASoC: codecs: wsa883x: fix PA volume control > ASoC: codecs: lpass-wsa-macro: fix compander volume hack > ASoC: codecs: wcd938x: fix headphones volume controls > ASoC: qcom: sc8280xp: limit speaker volumes > drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()' > > Only the last one can *potentially* be considered a CVE candidate, but > someone would actually have to take a *deep* look. Most likely it'll be a > functional issue, but not a security issue by any measures. > > So I hope it's not the case, and someone will actually be doing some > triage. If that's the case -- is this process described anywhere? It's described as "we know it when we see it" :) Seriously, this is something that Sasha has already been doing successfully for 3+ years now with the GSD project, so look at the commits that have been assigned there for an example of what will be picked. Also we will probably go back in time for a few years and use that data to populate the CVE database for older releases as long as they are still in currently supported releases as this is something that the CVE group has asked us to do already. As for your list above, I doubt any of those would be a CVE, give us some credit here. Let's see how it goes and if people complain we are picking things that we shouldn't be picking, OR if we aren't picking enough, they will then be asked to join the team doing the work :) The people that make up the current team, Lee, Sasha, and I, have a LONG history of fixing and triaging and managing security bugs for the kernel, in the community and in corporate environments. We know how to do this as we have been doing it for decades already. If you or anyone else wishes to help us out with this classification, we can gladly use the help. > Also, how are the CVSS-like scores going to be assigned? There are no > details whatsoever about that in the document. We will not be doing any CVSS scoring as that is outside the scope of a CVE entry and not required at all, and the CVE board agrees with this decision. As you well know, doing something like this for the kernel where we have no idea what your use case is, is almost impossible on the best days. There are external groups that suck in the CVE entries and attempt to assign CVSS-like scores to issues. It will be "interesting" to see how they classify things, but if the history of how well they have done this in the past is any indication, their tools need a lot of work and hopefully people stop relying on them and do the evaluation of their own use cases instead. > In any case, by making this change we are going to make security theathre > industry super-happy (they will have a lot of expensive nothing going on), > and all the distros not basing on -stable very unhappy (we're already > drowning because everybody and his grandma wants to become famous by > publishing a CVE for something completely irrelevant). If this is the > intention, it should be spelled out loud and clear. As we are not allowed to credit anyone in the publication of a CVE, I doubt the "I want a CVE!" group will get any louder than they currently are. And if it generates these people to actually submit bug fixes with their reports, all the better for us! I can't speak to the "security theatre industry" but right now, we have a real problem of external groups assigning random CVEs to the kernel with absolutely no input from us and no accountability, which is causing a lot of us real problems. This will take away the ability for those groups to continue to abuse our project just because of their broken engineering rules, and properly integrate them into our development process if they so desire to join in. thanks, greg k-h
