Amanita Security

A new CNA, a new CVE process

In February 2024, the Linux Kernel project started its own CVE Numbering Authority (CNA), which means that they will now directly handle the assignment of CVEs for vulnerabilities in the Linux Kernel.
While this could be a positive step forward, there is a risk of creating real complexities for product manufacturers due to its setup.

The challenge lies in the process the Kernel CNA team has chosen to assign CVE’s. To quote their CVE process[1]:
"[…] due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team."

Going forward, a large number of CVEs will be assigned for fixes that have no real security impact. A quick count of the linux-cve-announce mailing list shows that over 200 CVEs were assigned in the first 4 days of operation, the majority of which have no demonstrated security impact.

[1] https://docs.kernel.org/process/cve.html

New regulations complicate the challenge further

Assigning a CVE number for each bugfix neglects several fundamental real-world challenges, especially in the case of product manufacturing and electronic devices:

• Electronic devices are part of critical processes, and frequent updates introduce failure risk and are difficult to plan. They might be subject to testing, type certification, and possibly require a maintenance window to install them. It is something you only do when necessary. ‘Just’ running the latest version and performing frequent rolling updates is seldom a workable strategy for electronic devices deployed in the field.
• Engineering time is always in short supply and most teams lack the capacity to triage the volume of CVEs that are being generated. This restricts their ability to identify which CVEs are relevant for their product, but also to identify those that present a real vulnerability. Assigning CVEs for issues other than security vulnerabilities places the burden on each product organisation using Linux.
• The approach complicates upcoming compliance with cybersecurity regulations which make security updates for each known vulnerability mandatory.

Vulnerability management is fast becoming a common requirement of new legislation and regulation around the world. Examples of these are the Radio Equipment Directive and the Cyber Resilience Act.
To achieve this, the use of Software Bill of Materials (SBOM) is often legislated to support finding any known vulnerabilities for a particular component that is being used in a product.
Known vulnerabilities are in practice defined as ‘something with a CVE’. If any known vulnerabilities are present, the vendor is expected to fix these and provide a security update without undue delay to the asset owner.

The SBOM approach is not very granular as it relies on version numbering, and it cannot provide insights on whether a vulnerable code path of a CVE is ever reached, and thus relevant for the product in question.
With the approach the Kernel CNA team has chosen, all Kernel versions will have known vulnerabilities all the time, imaginary or not.

The additional argument that many devices are not connected to the internet and thus present reduced attack surface is insufficient going forward. As evidence of this, the updated EU Machinery Regulation makes a point that every product must have an adequate standard of cybersecurity, regardless of its operating context. Claiming that a product is part of an isolated network is thus no longer a valid reason to fail to integrate security controls in the product or to issue security patches.

Now that regulations prevent us from merely ignoring wrongly assigned CVEs, it’s evident that to triage and stay on top of security updates, we need engineers to take a closer look at the relevancy of vulnerabilities. Not every company has the capability to do this.

Longing for a perfect world

The CVE system might be far from perfect, a point clearly made in the Kernel CNA team’s introduction to their CVE process, stating that “Over time, their [CVE] usefulness has declined with regards to the Kernel project, and CVE numbers were very often assigned in inappropriate ways and for inappropriate reasons. Because of this, the Kernel development community has tended to avoid them.”

It is clear that the current process is based on the learnings, and frustrations, the team has faced in the past. The new process seems made for convenience, to limit the time Kernel engineers must spend on unproductive workflows.

While such a position can certainly be understood, it is difficult to comprehend how the usefulness of the system will be improved by assigning a CVE to each bugfix in the Linux Kernel. Additionally, assigning CVEs to all bugfixes out of “an abundance of caution” may be inappropriate. Typically, security researchers are held to higher standards when disclosing vulnerabilities. The expectation is that CVEs are assigned for ‘meaningful’ security vulnerabilities, and not for any software fixes that ‘might’ be a security vulnerability.

By taking this position, this effort is now duplicated across thousands of engineering teams ad infinitum, instead of handling it at the source, in a central, efficient and reliable manner.

Moving forward

Now that the Kernel CNA team has made their point, one can only hope that they will eventually be open to reconsider their approach to issuing CVEs, or at least engage in a discussion to make the CVE process more productive for everyone. Whether that can really happen still is to be seen.
Manufacturers should consider that any solution might not only need to come from the Kernel CNA team, and industry support could be required to tackle this for the benefit of all.

As a product manufacturer using Linux, there are a few options at this stage:

• While it is not certain this will be created, keep an eye on possible guidance from ENISA or CISA on this topic.
• For products in the EU market, become familiar with the requirements of regulations, such as the Radio Equipment Directive and the Cyber Resilience Act, as well as the product liability and safety directives.
• If you rely on a commercial Linux distribution, engage your vendor in conversation to see how they intend to balance regulatory needs with the expected volumes of CVEs, and how frequently you can expect updates.
• Consider strengthening internal security processes and capacity to triage CVEs and identify which ones apply to your specific situation.
• Consider the added maintenance cost due to this approach and, if necessary, evaluate alternative technology choices for future products.

Final thoughts

This article describes a possible outcome - it is a challenge to accurately predict future developments.

If events do evolve as described, the sheer amount and duplication of work that must be performed by security and engineering teams will be immense.
Every manufacturer will need to either triage the relevant issues for their product among the hundreds or thousands of irrelevant CVEs or create security updates that will need to be tested, distributed and applied on an almost daily or weekly basis.

Building secure and resilient products still requires the goodwill and collaborative approach of the parties involved. It does not happen in silos but requires an end-to-end perspective. If we can no longer rely on CVE information being meaningful, the entire ecosystem, with all its known issues, will be much less effective than it could be.