Linux CVE assignment process

How the Linux kernel assigns CVEs

The Linux kernel project is now a CVE Numbering Authority (CNA), responsible for issuing its own security advisories. This is a significant shift, as the kernel security team has historically never marked or announced security fixes.

The core challenge is identifying which fixes are security vulnerabilities within a massive, volunteer-driven project. The kernel sees an average of 9 changes per hour, but the CNA team has built a process to filter and review them.

The review process starts with bug fixes

Kernel developers have manually tagged commits as bug fixes for decades to enable backports to stable kernel branches. The CNA team uses this existing feed, which averages about 30 changes per day, as its primary source for review.

This focus is efficient. If a critical fix is missed in this feed, it will likely be requested for backporting later, ensuring it gets a review. The team evaluates each bug fix against the CVE.org definition of a vulnerability.

That definition is: “An instance of one or more weaknesses in a Product that can be exploited, causing a negative impact to confidentiality, integrity, or availability.”

What qualifies as a kernel CVE

At the kernel's level, many bugs can be considered vulnerabilities. The team has established clear criteria for what gets a CVE. A major category is fixes for user-reachable WARN() or WARN_ON() assertions.

This is because of the panic_on_warn kernel option. When enabled, a warning triggers an immediate system crash. This setting is used on billions of embedded systems and many cloud servers.

Because of this, any fix that resolves a user-reachable warning trigger must be assigned a CVE. The team states that without this setting, the total number of kernel CVEs "would greatly drop."

Common stable kernel updates that do not receive a CVE include:

• Build fixes (e.g., resolving compiler errors)
• Documentation updates
• "Theoretical" race conditions with no exploit path
• Code cleanups and refactoring

What doesn't get a CVE

Some bug types that might seem like vulnerabilities are excluded by the CVE.org rules. The kernel CNA team cannot assign CVEs for these, even if they disagree.

Filesystem corruption or data loss bugs are a key example. The author notes, "personally, I think that filesystem corruption or data loss bug fixes should be considered a CVE fix."

Additionally, CVEs are not assigned for crashes caused by mounting a maliciously crafted filesystem image—unless the userspace fsck program had previously run on it and found no problems.

For CPU hardware bugs like Spectre, the responsibility for CVE assignment lies with the hardware vendor, not the kernel CNA. The team notes that vendors often do not assign them, "but there is nothing that us as a CNA can really do about that."

A voting system with three core members

Three core team members review every commit applied to each stable kernel release. They work independently using different methods: one uses the email client Mutt, another uses a custom tool with LLM oracles, and a third uses regex and manual review.

Each member checks their list of potential vulnerabilities into a public vulns.git repository. An automated tool then tallies the votes.

A commit is marked for a CVE if at least two core members vote for it. The team also accepts and considers reviews from external community members and developers.

All this work is public in the vulns.git repository. CVEs are typically assigned one to two weeks after a fix lands in a released kernel, giving users time to update.

Handling mistakes and requests

The process allows for corrections. Developers or companies can request a CVE ahead of the review cycle by emailing the public CNA address, often for presentation deadlines or external reports.

Conversely, if anyone believes a CVE was assigned incorrectly—such as a subsystem maintainer who understands the code deeply—they can email the team to have it reviewed and often rejected.

The team can also update CVE records after assignment to clarify the vulnerable version range or add references to external reports, typically via a patch to the vulns.git repo.

The scale and impact on users

The Linux kernel CNA is now one of the most prolific, issuing about 60 CVEs per week. However, the team emphasizes this volume is misleading for end users.

Each CVE record includes the specific files affected and the exact git commit ranges where the vulnerability existed and was fixed. This allows for precise filtering.

Based on this data, the team estimates that on average, only 10 CVEs per week are applicable to any given Linux system, drastically reducing the manual review burden for system integrators.

The team strongly warns against using CPE identifiers for range checking, calling them "useless for any real range checking." They recommend always walking the git tree for accurate assessments.

Why severity scores are misleading

The kernel CNA team takes a firm stance against generic severity scoring. They state that kernel developers "have no way of judging the severity of any CVE fix for a user," as open-source software has infinite use cases.

They argue that any group, like NIST's NVD, that assigns a CVSS score to a Linux kernel CVE is "lying to you, UNLESS they know exactly your use case." They have asked NIST to stop this practice.

The only valid scoring, in their view, would come from consortiums of organizations with identical use cases, like cloud hosting companies. However, they note such groups have largely stopped scoring and instead opt to update kernels regularly.

The case for taking all stable updates

The team's overarching advice is to apply all stable kernel updates, not to cherry-pick individual CVE fixes. Kernel CVEs reference a single fix but do not account for prerequisite changes in the tree.

Cherry-picking creates an untested, unsupportable system and can cause users to miss critical non-security fixes for data corruption or performance.

"The bonus of just applying all stable releases is that you also get the data corruption and performance improvements for your system as well as the security updates," the author writes. "A result that many ecosystems have already realized is much simpler overall to do."