On Fri 16-02-24 12:25:46, Greg KH wrote: > On Thu, Feb 15, 2024 at 07:36:20PM +0100, Michal Hocko wrote: > > On Thu 15-02-24 19:20:09, Greg KH wrote: > > > On Thu, Feb 15, 2024 at 06:54:17PM +0100, Michal Hocko wrote: > > > > On Wed 14-02-24 09:00:30, Greg KH wrote: > > > > [...] > > > > > +Process > > > > > +------- > > > > > + > > > > > +As part of the normal stable release process, kernel changes that are > > > > > +potentially security issues are identified by the developers responsible > > > > > +for CVE number assignments and have CVE numbers automatically assigned > > > > > +to them. These assignments are published on the linux-cve-announce > > > > > +mailing list as announcements on a frequent basis. > > > > > + > > > > > +Note, due to the layer at which the Linux kernel is in a system, almost > > > > > +any bug might be exploitable to compromise the security of the kernel, > > > > > +but the possibility of exploitation is often not evident when the bug is > > > > > +fixed. Because of this, the CVE assignment team is overly cautious and > > > > > +assign CVE numbers to any bugfix that they identify. This > > > > > +explains the seemingly large number of CVEs that are issued by the Linux > > > > > +kernel team. > > > > > > > > Does the process focus only on assigning CVE numbers to a given upstream > > > > commit(s) withou any specifics of the actual security threat covered by > > > > the said CVE? > > > > > > Outside of the git commit text, no, we are not going to be adding > > > anything additional to the report, UNLESS someone wants to add > > > additional text to it, and then we will be glad to update a CVE entry > > > with the additional information. > > > > OK, so what is the point of having CVE assigned to such a commit without > > any addional information which is already referenced by the kernel sha? > > What is the actual added value of that CVE? > > It provides the proper signal to others that "hey, this is a > vulnerability that you might want to take if it affects you". OK, but stating that something is a vulnerability fix requires a proper analysis and this is a non trivial work. The wording here indicates that most of the fixes will gain their CVE. The existing process really sucks because there are just too many CVEs which really do not have any security implications but it seems that the new process is not going to address that because it will likely generate even more CVEs. > Right now > we are fixing lots and lots of things and no one notices as their > "traditional" path of only looking at CVEs for the kernel is totally > incorrect. Right, there are quite a lot of people who consider CVE fixes much more important than regular fixes. Their reasoning might be completely misleading but there might be very good reasons to stick to minimalistic approach, e.g. to reduce risk of regressions. I believe it is perfectly fair to say that whoever relies on stable kernels support needs to update to the latest stable kernel version to be covered by security and functional fixes. On the other hand I do not think it is an improvement to the process to swamp CVE database with any random fixes without a proper evaluation. If the kernel community doesn't believe in the CVE process then fair enough, just do not assign them unless you want to explicitly call out fixes with a high impact security implications. Having fewer good quality CVEs would definitely improve the process. > > > Here's an example of what the CVE announcement is going to look like for > > > a "test" that we have been doing for our scripts > > > https://lore.kernel.org/linux-cve-announce/2024021353-drainage-unstuffed-a7c0@gregkh/T/#u > > > > Thanks this gave me some idea. One worrying part is > > : Please note that only supported kernel versions have fixes applied to > > : them. For a full list of currently supported kernel versions, please > > : see https://www.kernel.org/ > > > > >From the above it is not really clear "supported by _whom_". Because I > > am pretty sure there are _fully_ supported kernels outside of that list > > which are actively maintained. > > Very true, how about this wording change: > For a full list of currently supported kernel versions by the > kernel developer community, please see https://www.kernel.org/ > > I added "by the kernel developer community", is that ok? That sound much better! > And as you're here, I have no objection to adding the vulnerable/fixes > info from various distros that are curently based on these same > kernel.org versions if you wish to provide them to me. I cannot speak for distro kernels in general. I can tell you that we at Suse do not base our product kernels on stable trees and we carefully evaluate backports we commit to support. -- Michal Hocko SUSE Labs
