On Fri 16-02-24 16:34:57, Greg KH wrote: > On Fri, Feb 16, 2024 at 02:20:04PM +0100, Michal Hocko wrote: > > > 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. > > As you know, it's almost impossible to determine if a fix is "high > impact" or not, given that we have no idea what anyone's use case is for > the kernel. We have documented proof of single-byte-buffer-overflows > resulting in complete system takeovers, and the same for very tiny > use-after-free issues, and the same for tiny "overflow a USB string > buffer" issues, and so on. Right, generally speaking this is not an easy task. It requires a lot of diligence actually. Sometimes there is no clear cut and that is _fine_. The CVE system cannot ever be bullet proof and mark every single security related fix (really you can be creating new security problems just by backporting upstream fixes into stable trees). But that is not really all that important, the main thing/question is whether it can be _useful_. If you simply assign CVE to any fix in stable you end up with thousands of CVEs and I really fail to see any practical benefit from that. Well, unless you want to DoS the system and its consumers. Who do you expect to be the user/consumer of those CVE numbers? You have already said that community supported stable kernels mandate the latest version to be used. Those users do not need to know there is $BIG_NUMBER of CVEs in them. If you want to mark a specific class of fixes with CVE because they are known to be used for exploits then fine! That is something actually useful. If you allow users to explicitly mark a fix as security relevant because of XYZ argument then really great! > So as always, we need to treat "a bug is a bug is a bug" and when > looking at the bug fix, if it resolves something that is known to be ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > a vulnerability (again, as defined by CVE themselves), then we need to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > mark it as such. I am completely with you on that! That is quite far away from what the documentation says AFAICS. > If you find that we are marking things as a CVE thatt you do not feel > should be marked as such, please let us know and we will be glad to > discuss it on a case-by-case basis. I've been through that exercise with the CVE process over years many times. It has always been a pain because you were not talking to domain experts who could evaluate the reasoning behind the dispute. I consider the new process of a clearly defined dispute process a big improvement! But if the real practice would be thousands of CVEs created for any stable backport then this will DoS many existing CVE consumers. All that being said. I do agree that taking control of CVEs and making that kernel community thing is a good thing! But I really fail to understand how increasing the number of CVEs by nominating all/most stable fixes is going to help anybody or improve the existing process. Thanks! -- Michal Hocko SUSE Labs
