How Linux Kernel Deals With Tracking CVE Security Issues
NAPA, Calif. — Like it or not, we depend on Common Vulnerabilities and Exposures (CVE)s bulletins to track security problems. These, in turn are assigned by CVE Naming Authorities (CNA). Who runs those, you ask? Well, soon, if you, your open-source project, or project will. Ready? Probably not.
CVEs are standardized identifiers for security vulnerabilities, and CNAs are entities authorized to assign these identifiers. Traditionally, companies like Red Hat and Oracle managed CVEs for open-source projects. This approach always has the problem that vendors, of course, focused on the relevant vulnerabilities to their products.
That’s not good enough anymore. Since the European Union (EU) Cyber Resilience Act (CRA) was passed any open-source software that used in a “commercial activity” must “put in place and document a cybersecurity policy, notify cybersecurity authorities of actively exploited vulnerabilities.” In short, you may very well need to become a CNA and issue CVEs.
There are other good reasons to do this. For example, you can make certain that that all vulnerabilities, regardless of use case, are identified and addressed. On the flip side, you can. As Red Hat developer Nikita Popov, put it on Ycombinator, you can “reduce the amount of bogus CVEs that are issued for your project due to security researchers trying to pad their portfolio.”
Half-Baked CVEs
A flood of half-baked CVEs can be a major pain. Just ask Daniel Stenberg, founder and lead developer of the popular open source command line copy tool cURL for transferring data via URLs, who’ve been fighting off bogus CVEs for years now. Because these wasted cURL’s developers time and energy, Stenberg decided in 2024 it was high-time to grab control of cURL’s CVEs and to “make it harder to file more stupid curl CVEs in the future.”
The Linux kernel developers also became a CNA the same year. As Greg Kroah-Hartman, the Linux stable kernel maintainer, wrote at the time, while he thinks “the [CVE] system overall is broken in many ways, but this change is a way for us to take more responsibility for this, and hopefully make the process better over time.” Kroah-Hartman added, “it looks like all open source projects might be mandated to do with the recent rules and laws.” That day has come.
At the Linux Foundation Member Summit, Kroah-Hartman said in a presentation that in the EU, the “CRA will make projects responsible, while the USA assumes projects are responsible. Because of that “open source projects can’t hide behind companies anymore.” In other words, “Red Hat looks out for Red Hat, not you.”
Fortunately, Kroah-Hartman continued it has become much easier for open-source organizations to become CNAs. That’s thanks to the work of the CVE.org and the Open Source Software Security Foundation (OpenSSF) it’s become much easier to become a CNA. To www how to do this and what to do to stay in good standing, GitHub has put together a useful CNA how-to guide.
What are security vulnerabilities that require a CVE? According to the CVE group, it’s “an instance of one or more weaknesses in product that can be exploited, causing a negative impact to confidentiality, integrity, or availability; a set of conditions or behaviors that allows the violation of an explicit or implicit security policy.”
However, Kroah-Hartman pointed out that some things you might assume are vulnerabilities, which would require a CVE, don’t get assigned one. For example, data corruption and performance issues are not considered CVE-worthy. Mind you, you might consider “an error that overwrites your disk with zeros” to be a serious problem. Greg certainly thinks, “if I lose my data, I’m going be mad. But since you didn’t ‘lose’ your data to an attacker, it’s not a ‘security issue.'”
While that view may continue to be how such cases are seen in the United States and China, which also uses CVEs, the EU may change its CVE rules. The officials in Brussels are considering including data corruption and system performance issues as matters that programmers, companies, and open-source organizations will need to track. Stay tuned.
Now that the Linux kernel developers are issuing CVEs, Kroah-Hartman explained that they also offering Linux security vulnerability information a public Git repo in JSON format. He “thinks all projects should have a public repo of this information in a readable form that can be scanned can be searched.”
That’s important because this can help you automate your CVE assigning, reporting, and resolution process. Trust me, you’re going to want to automate this process. The Linux kernel alone is averaging 94 CVEs a week. Don’t panic at the number, few of those CVEs will ever give you trouble. Kroah-Hartman added, “Being a CNA has resulted in large drop in false [CVE] negatives with a small bump of false positives with a net benefit for identifying fixed flaws.”
He continued that CVEs are issued only after patches have been made. There’s No pre-disclosure at all!” That’s because from the Linux kernel team’s perspective, “all ‘early notice’ lists are leaks.”
Another important point is that in the case of the Linux kernel and some other projects, such as cURL, they don’t assign Common Vulnerability Scoring System (CVSS) scores to their CVEs.These are the scores, ranging from 0.1 to 10, used to reveal the severity of a given security hole.
Why? As Greg explained, “Linux has many use cases.” For example, ” Famously, there was one Linux bug which was issued a very, very high-risk score because when it’s used in Android, you could take over a locked phone with that bug. Server people were like, “Why is this so high? It doesn’t affect us at all because that’s not our use case.” In the end, though, this CVE “ended up on the US government list that mandated all Linux systems had to take this fix even though it doesn’t matter at all on servers. So that for them, it had a CVSS score of zero.” So, if your project also has multiple use cases, he warns you might be better off staying away from assigning CVSSs.
Kroah-Hartman also strongly recommends all open-source projects should:
- Become a CNA so they can control their destiny.
- Write tools to automate things
- Save information in a neutral way
Yes, this will require more work, but besides being necessary to do business in the EU soon, done correctly, it will enable you to provide high-quality, detailed reports on vulnerabilities, including specific commits and affected code ranges. This, in turn, will enable your internal and external developers and even your users to better understand and address security issues.
