On Tue, Oct 08, 2024 at 01:35:24PM +0200, Pavel Machek wrote: > On Tue 2024-10-08 13:24:05, Greg Kroah-Hartman wrote: > > On Tue, Oct 08, 2024 at 01:16:28PM +0200, Pavel Machek wrote: > > > On Wed 2024-10-02 09:26:46, Jens Axboe wrote: > > > > On 10/2/24 9:05 AM, Vegard Nossum wrote: > > > > > Christophe JAILLET (1): > > > > > null_blk: Remove usage of the deprecated ida_simple_xx() API > > > > > > > > > > Yu Kuai (1): > > > > > null_blk: fix null-ptr-dereference while configuring 'power' and > > > > > 'submit_queues' > > > > > > > > I don't see how either of these are CVEs? Obviously not a problem to > > > > backport either of them to stable, but I wonder what the reasoning for > > > > that is. IOW, feels like those CVEs are bogus, which I guess is hardly > > > > surprising :-) > > > > > > "CVE" has become meaningless for kernel. Greg simply assigns CVE to > > > anything that remotely resembles a bug. > > > > Stop spreading nonsense. We are following the cve.org rules with > > regards to assigning vulnerabilities to their definition. > > Stop attacking me. I am doing no such thing. > > And yes, many bugs at this level (turns out about 25% of all stable > > commits) match that definition, which is fine. If you have a problem > > with this, please take it up with cve.org and their rules, but don't go > > making stuff up please. > > You are assigning CVE for any bug. No, it is not fine, and while CVE > rules may permit you to do that, it is unhelpful, because the CVE feed > became useless. Their rules _REQUIRE_ us to do this. Please realize this. > (And yes, some people are trying to mitigate damage you are doing by > disputing worst offenders, and process shows that quite often CVEs get > assigned when they should not have been.) Mistakes happen, we revoke them when asked, that's all we can do and it's worlds better than before when you could not revoke anything and anyone could, and would, assign random CVEs for the kernel with no way to change that. > And yes, I have problem with that. What exactly do you have a problem with? The number if CVEs can't be the issue as to make that smaller would mean that we would not document bugfixes that are going into our tree. Surely you don't want us to ignore them. > Just because you are not breaking cve.org rules does not mean you are > doing good thing. (And yes, probably cve.org rules should be fixed.) Again, we are following the rules as required by cve.org. If you feel we are not doing this properly, please let us know. If you feel that the rules that cve.org works with are incorrect, wonderful, please work with them to fix that up as you are not alone. Here's a talk I just gave, with slides, that explain all of this: https://kernel-recipes.org/en/2024/cves-are-alive-but-no-not-panic/ There was also a great BoF at the Plumbers conference a few weeks ago that went over all of this, and had actionable things for those that are working on the "downstream" side of the CVE firehose to do to help make things easier for those groups. Please work with the people running that if you wish to make things easier for anyone consuming the cve.org feed. greg k-h
