The Linux kernel is now the single largest issuer of CVEs — roughly fifty a week, with no severity scores attached, because the kernel community treats a CVE as an identifier for a fix, not an alarm. At the same time, the EU Cyber Resilience Act makes vulnerability handling a legal duty for anyone shipping connected products into the EU, with reporting obligations starting 11 September 2026 and full obligations from 11 December 2027.
The practical consequence: severity triage is now the device maker’s job, and the cheapest compliant strategy is the one the kernel community has recommended all along — stay on a maintained LTS kernel and take the point releases.
Two decisions, taken ten months apart, are reshaping how embedded Linux teams must handle security. In February 2024, kernel.org became the CVE Numbering Authority (CNA) for the Linux kernel and began issuing CVEs at a rate no other project approaches. In December 2024, the EU Cyber Resilience Act (CRA) entered into force and made vulnerability handling a legal obligation for products with digital elements sold in the EU. This article explains what each change means, where they meet, and what an embedded team should do about kernel CVEs before the deadlines arrive.
Kernel CVEs now outnumber everyone else’s
For most of its history, the kernel community left CVE assignment to outsiders, and the results were poor: numbers were assigned inconsistently, sometimes for bugs that were not vulnerabilities, and often without the involvement of the people who understood the code. Becoming a CNA fixed that — no one can now assign a kernel CVE without the kernel community — but it also changed the meaning of a kernel CVE.
The CNA team reviews the fixes flowing into stable kernels and assigns a CVE to any fix that may plausibly have security relevance. Greg Kroah-Hartman, who runs the effort with Sasha Levin and Lee Jones, reports that the project went from the third-largest CVE issuer in 2024 to the largest in 2025, at roughly fifty CVEs a week. Deliberately, none of them carry a CVSS severity score. The team’s position, documented in the kernel’s own CVE process documentation, is that evaluating reachability, severity, and impact for every configuration and workload is infeasible from the kernel’s side — a bug that is harmless on a server may be exploitable on your board, and only you can tell.
💡 Key insight: A kernel CVE is an index entry, not an alarm. The kernel community identifies which commits fix potential vulnerabilities; deciding whether each one matters for your product is now explicitly your job.
Everything is published openly: every kernel CVE is announced on the linux-cve-announce mailing list, and the complete records — including the scripts the CNA team uses — live in a public git repository:
raghu@techveda.org:~$ git clone https://git.kernel.org/pub/scm/linux/security/vulns.git
Each record identifies the commit that introduced the problem and the commit that fixes it, per affected stable branch — exactly the data an automated triage pipeline needs.
What the Cyber Resilience Act requires
The CRA applies to nearly every product with digital elements placed on the EU market, and most embedded Linux devices qualify. The dates to plan around:
| When | What applies |
|---|---|
| Dec 2024 | The CRA entered into force. |
| Sep 2026 | Reporting obligations begin: manufacturers must report actively exploited vulnerabilities and severe incidents in their products, starting with an early warning within 24 hours of becoming aware. |
| Dec 2027 | Full obligations apply: security by design, no known exploitable vulnerabilities at release, a documented vulnerability-handling process, and security updates through the product’s support period. |
Note what the vulnerability-handling duty covers: not just your application code, but every software component in the product — which means the kernel, and every kernel CVE that affects the version you ship. Manufacturers must identify and document components (an SBOM), address vulnerabilities without delay, and distribute security updates. For a connected embedded product, this is a description of a kernel maintenance pipeline with legal force behind it.
Where the two meet
Put the two developments together. Your device ships a kernel. The kernel community publishes roughly fifty new CVEs a week against the kernel, with no severity scores. The CRA requires you to have a documented process that handles vulnerabilities in your product’s components. A security auditor, a market-surveillance authority, or a customer can now ask a precise question: here are this month’s kernel CVEs — which ones affect your product, and what did you do about each?
Answering that question one CVE at a time does not scale. Reviewing two hundred CVEs a month, mapping each to your kernel version and configuration, backporting individual fixes, and documenting every decision is more engineering effort than simply taking the stable updates. This is the same conclusion the kernel community reached from the engineering side: cherry-picking individual CVE fixes leaves real gaps, because many security-relevant stable fixes never receive a CVE, and the ones that do are not ranked for you.
💡 Key insight: The CRA turns the kernel community’s long-standing advice into the lowest-cost compliance strategy. Tracking a maintained LTS kernel and taking its point releases addresses the full stream of fixes at once; cherry-picking addresses them one at a time, at far higher cost and with gaps.
One real difficulty remains: support periods. The CRA expects security updates through the product’s support period, which for many device classes will be five years or more. Most kernel LTS branches are currently maintained for around two years. That mismatch does not go away — it must be planned for, either by scheduling in-life kernel migrations to newer LTS branches, by building on an extended-support base such as the Civil Infrastructure Platform’s SLTS kernels, or by budgeting for a vendor that provides long-term kernel maintenance.
A practical plan for embedded teams
- Pick a maintained LTS kernel and take its point releases. Make the update path routine instead of exceptional; the whole-branch update is your primary CVE remediation mechanism.
- Automate CVE relevance triage. Use the vulns.git records to filter kernel CVEs against the branch, version, and configuration you actually ship, so humans review the short list, not the full stream.
- Maintain an SBOM and record decisions. The CRA expects you to know what you ship and to document how each relevant vulnerability was addressed — automation output is your audit trail.
- Make field updates a product capability. A remediation you cannot deliver is not a remediation; secure, signed OTA is the delivery half of the vulnerability-handling duty. (We covered building that foundation on Yocto in The Stack and the Fleet.)
- Plan the support period now. Match your product’s support commitment against LTS branch lifetimes and schedule the kernel migrations — or the extended-support arrangement — before the gap becomes an emergency.
The engineering skills underneath this plan — kernel configuration, stable-branch maintenance, and confident navigation of kernel source — are the ground TECH VEDA’s Linux kernel infrastructure training covers.
Key takeaways
- The kernel is now the largest CVE issuer — roughly fifty a week, deliberately without severity scores — because the CNA treats a CVE as an identifier for a potentially security-relevant fix.
- The CRA makes vulnerability handling, SBOMs, security updates, and incident reporting legal duties for products sold in the EU; reporting starts September 2026, full obligations December 2027.
- Severity triage against your specific kernel, configuration, and threat model is now the device maker’s responsibility — no upstream party does it for you.
- Whole-branch LTS updates are cheaper and safer than cherry-picking CVE fixes, and the vulns.git records make relevance filtering automatable.
- The LTS-lifetime versus CRA-support-period mismatch is real: plan kernel migrations or extended-support arrangements now.
Frequently asked questions
Does every kernel CVE affect my device?
No. Most kernel CVEs are in drivers or subsystems your configuration never builds. The CVE records identify the introducing and fixing commits per stable branch, so you can filter automatically for the kernel version and configuration you actually ship.
Why does the kernel not assign severity scores to its CVEs?
Because severity depends on configuration, workload, and threat model, which differ for every deployment. The kernel CNA’s documented position is that it cannot evaluate reachability and impact for every user, so it identifies fixes and leaves severity assessment to those who know the product.
What does the Cyber Resilience Act require for the kernel inside my product?
The kernel is a component of your product, so the vulnerability-handling duties cover it: identify it in your SBOM, address its vulnerabilities without delay, deliver security updates through the support period, and from September 2026 report actively exploited vulnerabilities you become aware of.
Is cherry-picking individual CVE fixes an acceptable strategy?
It is legal, but it is the expensive and risky option. Many stable fixes with security relevance never receive a CVE, and reviewing every CVE by hand costs more than taking whole LTS point releases, which is the approach the kernel community recommends.
Further reading
- Greg Kroah-Hartman — Linux CVEs, more than you ever wanted to know and Linux CVE assignment process
- Talks: The CRA and what it means for us (Kernel Recipes 2025) and CVEs are alive, but do not panic (Kernel Recipes 2024)
- Kernel documentation — CVE assignment process and the vulns.git CVE records repository
- LWN.net — How kernel CVE numbers are assigned (Lee Jones)
- European Commission — Cyber Resilience Act
