Linux kernel CVEs in embedded devices: triage by version, config and drivers, then fix

Because the kernel became its own CVE Numbering Authority (CNA) and decided to treat almost every bug fix as a potential vulnerability. Greg Kroah-Hartman announced on 13 February 2024 that Linux is a CNA, so that, as with curl, no other group can assign CVEs against the project without its involvement. The kernel's CVE process documentation explains the volume. Due to the layer the kernel sits at, "almost any bug might be exploitable to compromise the security of the kernel," and the exploit potential is often unclear when the bug is fixed, so "the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify."

The same page sets the rules a device maker has to work with:

• CVEs are assigned automatically "as part of the normal stable release process," and only after a fix is available and applied to a stable kernel tree. Each one is tracked by the git commit ID of the original fix.
• No CVE is assigned for an issue in a kernel version the Stable/LTS team does not actively support. Bugs in a distribution's or vendor's own kernel have to go to that distribution.
• Deciding whether a CVE applies is the user's job: "we do not know your use case, and we do not know what portions of the kernel that you use."

The resulting volume is large. Counted through the NVD API on 2026-11-11, CVE records whose source is the kernel CNA and that are not rejected number about 4,290 published in 2024 and about 5,680 published in 2025. For comparison, CISA's KEV catalog (version 2026.11.10) lists 32 Linux kernel entries in total, from every year and every assigner. A firmware scan that matches only the kernel version will therefore report hundreds or thousands of kernel CVEs against a single image, and nearly all of the triage work is deciding which ones describe code that is really there and reachable. The broader CNA rules behind this are covered in our CVE Numbering Authority rules guide.

More than a typical CVE record does, and the extra fields are what make triage possible. Records from the kernel CNA, published on the CVE Program site and announced on the linux-cve-announce list, list the source files the fix changed (programFiles), the git commit ranges affected, and a per-branch version range. The CVE-2024-53104 record, an out-of-bounds write in the USB Video Class webcam driver, is a good example:

The per-branch list matters because each stable branch gets its own fixed release. A 6.1.120 kernel is fixed, even though it is numerically far below 6.13, and a scanner that compares every kernel with the mainline fix release will flag it wrongly. Downstream kernels add another layer. Debian's security tracker for CVE-2024-53104 records the fix for its bullseye 5.10 package in 5.10.234-1 (advisory DLA-4075-1), not at the upstream 5.10.230. So a fixed version always has to be read against the kernel tree the product actually ships.

Work from coarse to fine, so each step removes CVEs before the next, more expensive step:

Version. On a vendor board-support kernel the version string alone can mislead, because the SoC vendor may have applied hundreds of its own patches and sometimes upstream fixes as well. The kernel.org releases page states that kernel developers "can provide no support" for distribution kernels, and that anything after the dash in uname -r marks one.

Configuration. The build's .config is the best evidence. If only the image is available, the kernel's init/Kconfig describes CONFIG_IKCONFIG as saving the complete .config inside the kernel, extractable "with the script scripts/extract-ikconfig" or, with CONFIG_IKCONFIG_PROC, readable at /proc/config.gz on a running device. Yocto Project builds can record it in the SBOM through SPDX_INCLUDE_KERNEL_CONFIG, as our Yocto and Buildroot SBOM guide explains.

Mapping a file to an option. Each kernel directory's Makefile ties object files to a Kconfig symbol. For CVE-2024-53104, drivers/media/usb/uvc/Makefile builds uvc_driver.o into uvcvideo and has the line obj-$(CONFIG_USB_VIDEO_CLASS) += uvcvideo.o. A smart meter or industrial gateway built without CONFIG_USB_VIDEO_CLASS does not contain the vulnerable code at all. The same reasoning applies to the other KEV-listed USB bug, CVE-2024-53197 in sound/usb/quirks.c, which is built only with CONFIG_SND_USB_AUDIO.

Recording the result. A CVE ruled out at step 2 or 3 is a VEX statement of "not affected" with the justification that the vulnerable code is not present, and the config line is the evidence. Our CSAF and VEX for device makers guide covers how to publish that to customers. Re-run the mapping when the .config changes. A new feature that enables one option can bring a whole subsystem's CVEs back into scope.

Move to the latest release of a longterm branch, and keep moving. The kernel's CVE documentation is direct: "it is best to take all released kernel changes, as they are tested together in a unified whole," not cherry-picked fixes, and it warns that some relevant changes carry no CVE at all. The stable kernel rules explain why those updates are low-risk. A stable patch "must already exist in Linux mainline," must be "obviously correct and tested," and cannot be bigger than 100 lines with context. As of the kernel.org releases page read on 2026-11-11, the longterm branches and their projected end of life are:

Two branches common in shipped devices, 5.10 and 5.15, reach their projected kernel.org end of life in December 2026. Once that happens, the kernel CNA stops assigning CVEs for them, and that is no sign that they have stopped having bugs.

Use CIP SLTS for long-lived products. The Civil Infrastructure Platform provides Super-Long-Term Stable kernels "with a maintenance period of ten years," starting from the standard LTS kernels and allowing some hardware-support backports. Its Kernel Working Group's ten-year review lists the supported series in the table above, plus 4.4.y (until 2027) and 4.19.y (until 2029). These two are kept on a self-maintenance model "limiting them to a subset of architectures and member-provided configurations." The same post describes the group's cip-kernel-sec CVE tracking and a kernel-cve-triage tool "to identify CVEs affecting specific kernel configurations", the same config-based triage described above. Check that your SoC and configuration fall within CIP's supported scope before relying on it.

Backport only when you cannot rebase. A SoC vendor's board-support kernel pinned to an old release is the usual reason. Take the upstream fix commit named in the CVE record, plus any follow-up fixes to the same code, and run the full test suite. Record each backport against its CVE, because a version-only scanner will still flag the kernel as affected. Over time, the cheaper path is to push the board support upstream or onto a longterm branch.

Disable what the product does not use. The kernel's self-protection documentation calls attack surface reduction "the most fundamental defense against security exploits." For an embedded image, the practical form is a minimal .config. Each unused filesystem, protocol family, USB class driver or debug interface that is turned off removes a whole stream of CVEs from scope. Limiting attack surfaces is also one of the essential requirements in the EU Cyber Resilience Act, covered in our CRA Annex I guide. The kernel is only one of the open-source components in an image that need this treatment. See our BusyBox vulnerabilities guide and U-Boot bootloader security guide for the components next to it, and firmware OTA update security for getting the fixed kernel onto devices in the field.

SoftWSP's automated scan unpacks a firmware image and catalogs the software components in it. Where the image's package records list the kernel, for example the opkg kernel package on OpenWrt-based firmware, it identifies the component as the Linux kernel with its version, strips the package revision so the upstream version can be matched, and matches that version against CVE records, CISA's KEV catalog and FIRST's EPSS scores. This is deterministic code: the code scores, and AI narrates.

AI's part is the written explanation on top of that matching. It summarises which kernel CVEs matched the version, which ones are KEV-listed or have a high EPSS score, and what the version evidence was, and every sentence cites the component, version and record it relies on. An engineer reviews every finding before the report is delivered. The steps this guide describes as manual stay with that engineer: reading the kernel .config, mapping each CVE's source files to CONFIG_* options, checking which modules ship, and judging whether a driver is reachable on the hardware. A version-only match also flags CVEs that a vendor backport has already closed, and that judgement stays with the engineer too. Our firmware SBOM guide covers how the component inventory itself is built.

For where kernel review fits in a full assessment, see the OWASP Firmware Security Testing Methodology guide, or device & firmware security services to have a specific image reviewed.

This guide draws on the Linux kernel's CVE, stable-release and self-protection documentation, Greg Kroah-Hartman's CNA announcement, the kernel.org releases page, the Civil Infrastructure Platform's SLTS pages, CVE Program records for CVE-2024-53104 and CVE-2024-53197, the Debian Security Tracker, kernel source Makefiles and Kconfig, NVD API counts by source and CISA's KEV catalog (version 2026.11.10), all read directly on 2026-11-11.