On 24/10/08 01:44PM, Greg Kroah-Hartman wrote: > 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. Here is the timestamped link to the BoF session at the plumbers conference: https://www.youtube.com/live/SWj-0FcyDWk?si=jx6Vv8Xdzm_qKekj&t=11410 > greg k-h Cheers, Chris
Attachment:
signature.asc
Description: PGP signature
