Only some. The Linux kernel CVE team assigns CVEs to a very wide set of fixes, and the kernel documentation says large numbers of them are not relevant to a given system. Narrow the list by supported version, your build configuration, and whether the affected code is reachable.
Why the list is so long
The kernel documentation on CVEs explains that the assignment team is "overly cautious" and assigns a number to any bugfix it identifies as potentially security relevant, because almost any bug might be exploitable at that layer. That explains the large count.
It also says plainly that applicability is the user's job. Because "any one system only uses a small subset of the source tree", many assigned CVEs are not relevant to a particular system, and the team cannot know your use case.
Four filters for embedded teams
- Supported branch. The documentation states that no CVEs are assigned for versions that are not actively supported by the Stable/LTS team, and that issues in a distribution only kernel must be handled by that distribution. If you run a vendor kernel, find out who issues advisories for it.
- Fix timing. CVEs are assigned after a fix is applied to a stable tree and tracked by the commit id of the original fix. So check whether your kernel version already contains that commit, which may be true even when the version number looks old because of backports.
- Build configuration. A driver or subsystem that is not compiled in cannot be exploited through your device. Compare the file touched by the fix against the objects in your build. This is the filter that removes the most noise.
- Reachability. If the code is compiled in but no path from an attacker, a peripheral or a user process leads to it, record that reasoning.
Record your decisions
Each decision should be written down once, not rediscovered at every release. For a CVE you rule out, store the CVE id, the kernel version, the config evidence and the date. A machine readable VEX statement is a good format, and the OpenVEX specification includes the justification label vulnerable_code_not_present for the case where a feature is simply not built.
What not to do
Do not cherry pick single patches out of the stream and assume you are covered. The kernel documentation advises taking released changes as a tested whole rather than individual cherry picked changes, and notes that a full fix may be several changes on top of each other.
Do not treat a missing CVE as proof of safety either. The same text says some fixes will be missed, so some changes without a number might still matter.
Try it yourself
Open the reachability demo and see how filtering by whether code is actually used shrinks a finding list. The same idea applies to kernel configuration.
Click through it at your own pace, or open it full screen.
Safeguard offers reachability analysis for application dependencies. Kernel configuration review for a firmware image is still work your platform team does by hand or with build tooling.
Quick check
Is every kernel CVE a real risk to my device?
No. The kernel documentation says large numbers of assigned CVEs are not relevant to a given system.
Who decides if a kernel CVE applies to me?
You do. The kernel CVE team says it does not know your use case or which parts of the kernel you use.
Sources
Last reviewed: 19 October 2026.
