Linux Kernel CVEs: How Backports Change Vulnerability Exposure

Introduction

The objective behind generating a Software Bill of Material (SBOM) for the firmware you build, integrate, or deploy is not only to know which software component and version are present, but to map those component versions to known vulnerabilities.

Traditionally, this mapping between a component and its version to a given set of publicly known vulnerabilities has been done with the Common Platform Enumeration (CPE). The CPE is a string that explicitly defines affected components with the following format: cpe:<cpe_version>:<part>:<vendor>:<product>:<version>:<update>:<edition>:<language>:<sw_edition>:<target_sw>:<target_hw>:<other>. CPEs are themselves attached to CVEs.

For vulnerabilities that may be documented but not in the official CVE database, PURLs are used with the following standardized format: scheme:type/namespace/name@version?qualifiers#subpath.

This mechanism works well but has two major limitations:

1. Correctness. The CVE Numbering Authority (CNA) assigns the right CPEs and maintain the set of CPEs for the CVEs he’s published over time.
2. Expressivity. A CPE does not provide sufficient information about the specific conditions required for a CVE to be reachable and exploitable. This includes affected module, function, feature, etc.

We want to explore those two limitations and explain what we do at ONEKEY to address them so that our customers are not swimming in false positives. We will do so by illustrating our points with two operating systems: the Linux Kernel, and Android OS.

Today, we start with the Linux kernel.

Linux Kernel Context

A Common Platform Enumeration says which product and version an advisory describes. That makes CPE extremely useful for joining a component inventory to a vulnerability catalog. It does not claim to prove that a particular firmware binary contains the vulnerable code path.

The problem is that the Linux CNA does not always seem to keep CPEs updated when maintainers backport patches. Thankfully, projects like ubuntu-cve-tracker, kernel-sec, and cip-kernel-sec maintain datasets with information about those backports that we can use to refine CPE information.

We use three careful terms throughout this analysis:

• Raw NVD candidate: a pre-merge NVD CPE matcher includes the tested kernel version.
• Backport-aware candidate: the same member of the raw comparison population remains after applying kernel-vulns and CIP branch ranges through ONEKEY’s production merge strategy.
• Assessment refinement: additional deterministic evidence changes the amount or quality of work required. We reserve false positive for a case independently demonstrated to be unaffected.

The pinned raw NVD feed we used contains 14,269 kernel CVEs with a linux:linux_kernel CPE matcher. The post-merge database contains 14,503 kernel CVEs, including advisory-only coverage that is reported separately rather than smuggled into the reduction denominator.

Stable branches do not move in lockstep

Mainline fixes are routinely backported to maintained stable branches. The fix may land at 4.14.x, 5.4.y, and 5.15.z on different dates and sublevels. A range shaped only around an upstream version can therefore remain intentionally broad long after a particular stable kernel has received the fix.

Our pipeline preserves the two stages needed to measure this honestly. It parses the raw NVD matchers from the pinned source tree first. It then applies a merging strategy: kernel-vulns data is authoritative where present; CIP data supplies embedded-LTS history, with non-conflicting NVD ranges filling gaps.

At Linux 4.4’s final patch release, the raw comparison contains 4,226 candidates and 2,692 remain after stable-branch context, a 36.3% candidate reduction. At the current Linux 6.18 patch release, the corresponding counts are 77 and 58, a 24.7% reduction.

Those numbers are not a scorecard for NVD quality. The NVD population is the discovery baseline; the second population answers a more contextual question with newer and branch-specific evidence.

Sublevels are where the backport story becomes visible

A single “latest LTS” comparison can hide the mechanism. For 4.14, 5.4, and 5.15 we therefore selected the first patch release, the index midpoint of the chronological patch series, and the final or current patch release. The selection rule was fixed before counting.

These plots let two things happen independently. NVD’s version ranges may continue to discover a similar population across sublevels, while stable-branch ranges change exactly where backported fixes land.

For example, the first Linux 5.15 patch release moves only from 6,800 raw candidates to 6,521 backport-aware candidates, a 4.1% reduction. The final/current sample reaches 1,118 remaining candidates, but the early weak result stays in the plot.

Coverage is not reduction

Version refinement still does not tell us what a firmware image compiled. ONEKEY runs Automated Impact Assessment to make sure we don’t report things that aren’t there:

Automated Impact Assessment analyzes extracted firmware files to identify and hide non-exploitable vulnerabilities. Essentially, this feature acts as a filter that allows you to focus on relevant vulnerabilities, streamlining the triage process.

A vulnerability is deemed "non-exploitable" if:

1. The affected version is different from the one in your firmware.
2. The vulnerability affects a feature or module that was not compiled in.
3. The vulnerability affects a feature that is not explicitly used by the firmware.

For example, if a vulnerability is only exploitable over Bluetooth, but your firmware runs on a Linux kernel without a Bluetooth submodule, the platform automatically filters this out.

For CVEs affecting the Linux Kernel, we can automatically derive two kinds of rules:

• Kernel source rule: attach function and source file information to a CVE
• Architecture rule: attach architecture information to a CVE

When a Linux firmware is scanned, we extract kernel symbols from the kernel itself and all kernel modules. These symbols are mapped to files and functions through per-version lookup tables. From there, we can use that information with the kernel source rules to check whether the code is there or not.

For architecture rule, we simply check whether your kernel is built for the architecture affected by a given CVE.

The chart below shows the share of kernel source and architecture rules per Linux LTS versions. “Any automated rule” is there to show the share between automated rules and manually written rules.

We deliberately do not subtract those rule-covered CVEs here. A source rule can produce positive evidence, negative evidence, or no usable evidence depending on the binary. Architecture context likewise needs a detected architecture. Coverage describes the potential for further assessment; reduction requires a concrete firmware image and an explicit decision rule.

Real World Samples

To make the next step concrete, we analyzed official Raspberry Pi 4bcm27xx/bcm2711 squashfs factory images from the final or current patch release of five consecutive OpenWrt release lines: 21.02.7, 22.03.7, 23.05.6, 24.10.7, and 25.12.5.

For OpenWrt 21.02.7, kernel detection found the version recorded in the trace and produced 4,479 raw NVD candidates. Backport-aware ranges removed 802 from that comparison population. Within the same NVD comparison population, Automated Impact Assessment then produced 2,830 negative-score, 80 zero-score, and 767 positive-score final matches.

For OpenWrt 25.12.5, the same fixed process starts with 292 raw candidates, removes 80 through backport-aware ranges, and yields 212 final matches across all score signs in that comparison population.

The score is an evidence balance, not a CVSS replacement and not an exploitability oracle. A negative score means the collected automated evidence weighs against impact under the configured rules. Zero means the analysis found the candidate but did not move the evidence balance. A positive score means supporting evidence was found.

Key Takeaways

XXX

‍