A turning point for CVE numbers

Posted Feb 16, 2024 0:31 UTC (Fri) by sashal (✭ supporter ✭, #81842)
In reply to: A turning point for CVE numbers by pbonzini
Parent article: A turning point for CVE numbers

I mean... how do you want me to respond to this? Unless RH replies with a statement saying that the only reason they assigned a CVE to this is because they needed to backport a patch (and a statement that says "... for backport to older versions of Red Hat Linux ... " is not enough) to convince you that this is what is going on, then I'm not sure if it's worth discussing it here.

Given that you feel that we should go for completeness around our CVE reporting, I'm more than happy to personally check the CVEs assigned by kernel.org against RH's kernel trees, and request CVEs for issues that may affect RH's trees explicitly from the RH CNAs.

A turning point for CVE numbers

Posted Feb 16, 2024 3:34 UTC (Fri) by dgc (subscriber, #6611) [Link] (1 responses)

> I'm more than happy to personally check the CVEs assigned by kernel.org
> against RH's kernel trees, and request CVEs for issues that may affect RH's
> trees explicitly from the RH CNAs.

That escalated quickly, didn't it?

We've gone from LTS maintainers defending kernel developers against bad CVEs straight to LTS maintainers using their new authority to make extortion threats towards independent downstream CNAs in the space of a few discussion points.

It's no wonder there's a significant amount of distrust of this new power grab by the LTS maintainers. It will do nothing to lighten the CVE-related workload of downstream distros, and they seem to think nothing of using their authority as a weapon against independent, competing stable kernel products.

A turning point for CVE numbers

Posted Feb 19, 2024 13:53 UTC (Mon) by sashal (✭ supporter ✭, #81842) [Link]

What authority? Anyone can request a CVE against a CNA.

A turning point for CVE numbers

Posted Feb 16, 2024 4:50 UTC (Fri) by pbonzini (subscriber, #60935) [Link] (1 responses)

> and a statement that says "... for backport to older versions of Red Hat Linux ... " is not enough

I've been working with Red Hat kernels for 15 years and I can confidently say that a CVE number is neither necessary nor sufficient to commit to old releases. For example https://git.kernel.org/pub/scm/virt/kvm/kvm.git/commit/?h... will be in 8.6 soon and it does not have a CVE.

This statement was from someone who is clearly not too fluent in English, in fact the only way I can make *any* sense of the sentence is if it refers to the Bugzilla rather than the CVE. I understand that the grammar makes you read it like that, and I understand how this was annoying to you so I thanked you for showing it to me. But please concede that I might know Red Hat policies better than you, will you?

A turning point for CVE numbers

Posted Feb 19, 2024 13:59 UTC (Mon) by error27 (subscriber, #8346) [Link]

Sasha's example is from 2024 but people have been complaining about the "file for a CVE" life hack for years... I'm not in a position to know how common it is to do it in real life though.

A turning point for CVE numbers

Posted Feb 16, 2024 13:44 UTC (Fri) by hkario (subscriber, #94864) [Link]

See https://access.redhat.com/support/policy/updates/errata

it clearly states that Urgent Priority Bug Fix Advisories (RHBAs) can be fixed in extended support channels.