A turning point for CVE numbers [LWN.net]

A turning point for CVE numbers

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

How about something like CVE-2024-0562?

to post comments

A turning point for CVE numbers

Posted Feb 15, 2024 6:04 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (8 responses)

I don't think this proves that having a CVE was "necessary to include the bug in older releases". The security impact was missed back in 2022; it's been assessed only now, and this process included filing a CVE. Apart from the affected RHEL releases there are likely millions of devices that have the issue.

But yeah, I can see that it's a nuisance from the upstream point of view and I agree that assigning the CVEs proactively can be an improvement.

A turning point for CVE numbers

Posted Feb 15, 2024 13:47 UTC (Thu) by sashal (✭ supporter ✭, #81842) [Link] (7 responses)

Paolo, look at the RH bugzilla ticket for the CVE (https://bugzilla.redhat.com/show_bug.cgi?id=2258475). Quoted verbatim:

"""
This one is for backport to older versions of Red Hat Linux, because original request was:
"reported experiencing a UAF in RHEL8.6."
"""

RH *explicitly* called this out as something done to backport this patch to older releases.

A turning point for CVE numbers

Posted Feb 15, 2024 15:51 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (6 responses)

It is true that most things going into 8.6 at this point are fixes for vulnerabilities, and it is true that according to RHEL policy CVEs are created for every vulnerability that is fixed and can affect customers.

However that doesn't mean that Red Hat creates CVEs *because otherwise the backport wouldn't be allowed*. For example, a serious bug in 8.6 can be fixed without a CVE, and a low priority vulnerability wouldn't be fixed even with a CVE. (Also, giving an artificially high CVSS would be against Red Hat's interest for multiple reasons—it gets noticed and decreases credibility, forces customers to scramble, and imposes stricter deadlines that everyone would rather avoid).

I do agree that this is one case in which the new process can help, in multiple ways: 1) it makes it easier for distros not using LTS to identify candidate backports 2) it prevents confusion if Red Hat and friends do a late backport, and it gives a heads up to the upstream CVE team if Red Hat decides to assign a security impact to a fix a couple years down the line 3) it *may* provide impetus for manufacturers of embedded Linux products to get their act together and keep the f***ing kernel up to date, through either Linux LTS releases or distro vendors.

So I appreciate the example. However, I think you're reading from it a gaming of Red Hat policies that isn't there.

A turning point for CVE numbers

Posted Feb 16, 2024 0:31 UTC (Fri) by sashal (✭ supporter ✭, #81842) [Link] (5 responses)

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 (guest, #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.