Closing the Kernel Backport Gap: Automated CVE Detection for the EU CRA (Cyber Resilience Act)

by Shawn Chang

The EU Cyber Resilience Act (CRA) - Regulation (EU) 2024/2847 - entered into force on December 10, 2024. It is the EU’s first horizontal law that legally mandates secure-by-design for every “product with digital elements” placed on the European market. Manufacturers must now demonstrate compliance with a set of essential cybersecurity requirements throughout the entire product lifecycle, backed by enforceable penalties and market surveillance.

The CRA’s essential requirements are structured in two parts of Annex I, and are being translated into harmonized standards by three project teams under CEN-CENELEC:

PT1 (EN 40000-1-2) – Principles for cyber resilience. A process-oriented “catch-all” standard ensuring products are developed and maintained using a risk-based approach, covering secure development lifecycles, threat modeling, and security testing.
PT2 (EN 40000-1-4) – Generic security requirements. A product-oriented standard mapping the CRA’s 13 essential security requirements (Annex I, Part 1, points a–m) to a catalog of technical controls. These cover: shipping without known exploitable vulnerabilities (a), secure-by-default configuration (b), automatic security updates (c), access control and authentication (d), encryption of data at rest and in transit (e), integrity protection (f), data minimization (g), resilience and availability (h), limiting attack surfaces (i), exploitation mitigation mechanisms (k), security logging and monitoring (l), and secure data deletion (m).
PT3 (EN 40000-1-3) – Vulnerability handling requirements. A process standard mapping to Annex I, Part 2, requiring manufacturers to identify and document vulnerabilities (including SBOM), remediate without delay, conduct regular security tests, publicly disclose fixed vulnerabilities, maintain a coordinated vulnerability disclosure policy, and distribute security updates free of charge and without delay.

The harmonized standards for PT1 and PT2 will make modern mitigations – CFI (PaX RAP, PAC/BTI, Intel CET), DFI (PaX KERNSEAL/AUTOSLAB, ARM MTE, VED), and capability-based approaches (CHERI, FIL-C) – the de facto baseline for compliance. But PT3 demands something harder: proper tracking of active exploits and potentially exploitable vulnerabilities across your entire product lifecycle.

For the Linux kernel, this is a problem that no one has solved at scale.

The Problem: A Broken Chain

When a kernel vulnerability is discovered and fixed upstream, the fix doesn’t magically reach every device. It must travel through a long chain:

Upstream fix → Stable branch backports → Distribution backports → End users

At each step, backports can be partial, delayed, or missed entirely. Only a few GNU/Linux distro has full-time kernel maintainers while Only PaX/GRsecurity consistently provides high-quality backports across the board based on risk. Embedded vendors – automotive, industrial control systems, IoT devices built on Yocto/AOSP – are especially exposed. Many lack dedicated security teams, have no process for security audits or backport review, and simply don’t know which CVEs remain unfixed in their deployed kernels.

Meanwhile, the CVE flood continues. Since the Linux kernel became a CNA, the volume of assigned CVE numbers has grown dramatically, making manual tracking impractical.

The Risk Model Has Changed

CVE-based risk analysis is no longer sufficient. The traditional approach — prioritizing fixes based on whether a public PoC or exploit exists — assumed that writing a working exploit required significant expertise and effort. AI (especially Claude Opus at the moment) has changed that equation. Large language models can now assist attackers in developing exploits for vulnerabilities that previously had no known proof-of-concept, dramatically lowering the barrier to weaponization. For the first time, an AI (Claude) has autonomously developed a state-of-the-art kernel RCE (CVE-2026-4747). It handled everything from offset discovery and gadget hunting to multi-packet BSS overwrites, ROP construction, thread hijacking, and even cleanup for a working reverse shell.

A CVE without a public exploit does not mean low risk. It means the exploit hasn’t been published yet. This may affect how CRA enforce of vulnerability handling in the future.

This is why the industry must shift from CVE-centric risk scoring to attack surface and exploit vector analysis. What matters is not whether someone has already written an exploit, but whether the vulnerable code path is reachable, what primitives it exposes, and what mitigations stand between an attacker and successful exploitation. This is exactly why the CRA’s PT2 emphasizes exploitation mitigation mechanisms (k) and limiting attack surfaces (i) — and why defense-in-depth matters more than ever.

What We Built

Kernel Backport Checker is a command-line tool that answers a simple question: which kernel CVEs are actually fixed in my kernel, and which are still open?

It works by:

Scanning NVD for CVEs affecting your specific kernel version using CPE matching
Filtering by .config – if a vulnerable subsystem is disabled, the CVE is marked not applicable
Extracting fix commits from NVD references and git log (upstream + stable repos)
Verifying fixes in source code using a multi-phase algorithm: fingerprint matching, line-swap ordering detection, code-relocation detection, and context-aware adjacency checks
Producing a CSV report with verdicts: FIXED, LIKELY_FIXED, UNFIXED, INCONCLUSIVE, or NOT_APPLICABLE

The tool is conservative by design. Context-aware matching is used only to downgrade verdicts, never to upgrade them – because validation showed that context-based upgrades produced a 100% false positive rate. Small fixes with few distinctive lines are treated skeptically. Mixed signals across stable branches produce LIKELY_FIXED rather than FIXED.

A Real-World Run

First, set up the data repositories:

./setup-repos.sh -a -d ../

Then run the checker:

./kernel-backport-checker.sh \
    -s ../linux-6.1.1 \
    -d ../linux \
    -b ../stable \
    -e ../kev-data/ \
    -f ../nvd-json-data-feeds \
    -k ../linux-6.1.1/.config \
    -o output

The tool walks through each phase:

========================================
 Kernel Backport Checker v3.2.0
========================================

[INFO] Configuration:
[INFO]   Kernel Source:   ../linux-6.1.1
[INFO]   Kernel Config:   ../linux-6.1.1/.config
[INFO]   Git Repository:  ../linux
[INFO]   Stable/Vendor:   ../stable/
[INFO]   KEV File:        ../kev-data//known_exploited_vulnerabilities.json
[INFO]   NVD Feeds:       ../nvd-json-data-feeds
[INFO]   Output:          output
[INFO]   Parallel Jobs:   8

[INFO] Detecting kernel version...
[INFO] Kernel version: 6.1.1
[INFO] Loading kernel config: ../linux-6.1.1/.config
[INFO] Loaded 8802 enabled CONFIG options
[INFO] Building CONFIG mapping from kernel Makefiles...
[INFO] Built CONFIG mapping: 18386 file mappings, 1646 directory mappings
[INFO] Using cached NVD scan: output/.nvd_kernel_cves_6.1.1.tsv
[INFO]   (Delete output/.nvd_kernel_cves_6.1.1.tsv to force rescan)
[INFO]   Cached: 4710 CVEs affecting kernel 6.1.1
[INFO] Using cached NVD fix refs: output/.nvd_fix_refs_6.1.1.tsv
[INFO]   Cached: fix refs for 4606 CVEs
[INFO] Building git hash index...
[INFO] Git hash index built: 1917126 commits
[INFO] Extracting backported CVE fixes from git...
[INFO] Searching stable/vendor repo for CVE mentions: ../stable/
[INFO] Found 4261 commit-CVE pairs (705 unique CVEs in git)
[INFO] Building CISA KEV index...
[INFO] KEV index built: 1554 CVEs
[INFO] Processing results...
[INFO]   Matching fix commits against git repos...
[INFO]   Found 26200 fix commits in git repos
[INFO]   Extracting changed files and diffs from fix commits (jobs=8)...
[INFO]   Exporting lookup tables for parallel processing...
[INFO]   Processing 4710 affected CVEs (jobs=8)...
[INFO]   Processing complete.
[INFO] Generating CSV report...
[INFO] ===========================================
[INFO] Report: output/backport-report.csv
[INFO] ===========================================
[INFO] 
[INFO] Summary for kernel 6.1.1:
[INFO]   Total CVEs:              4710
[INFO]   Not applicable:          527
[INFO]   Applicable:              4183
[INFO]     Fixed via backport:    1
[INFO]     Likely fixed (review): 5
[INFO]     Unfixed (remaining):   3465
[INFO]     Inconclusive:          712
[INFO] 
[INFO]   CVEs in CISA KEV:        9 (fixed: 0)
[INFO] 
[INFO]   Severity (applicable / unfixed):
[INFO]     CRITICAL:              17 / 9
[INFO]     HIGH:                  1225 / 1006
[INFO]     MEDIUM:                2921 / 2432
[INFO]     LOW:                   20 / 18

[INFO] Done!

3,321 unfixed CVEs. Nine in CISA’s Known Exploited Vulnerabilities catalog – none fixed. That’s the visibility gap this tool addresses.

No Source Code? No Problem

For scenarios where only a compiled kernel binary is available – firmware images, embedded devices, field-deployed systems – the companion Binary Checker performs CVE detection directly against vmlinux. It extracts kernel metadata, generates fix signatures from upstream git diffs, and matches them against the binary using string patterns, symbol changes, and optional function-level comparison via radare2.

Validating the Verdict

For compliance purposes, you need confidence in the results. The tool includes four validation scripts:

validate-single-cve.sh – tests a single CVE by attempting to apply the upstream fix patch. If the patch applies cleanly, the fix is not present (ground truth = UNFIXED).
validate-all.sh – runs validation across all applicable CVEs in parallel, with filtering by verdict type
validate-with-patches.sh – end-to-end test: applies fix patches to the source, re-runs the checker, verifies CVEs are now detected as FIXED or LIKELY_FIXED, then reverts
find-patchable-cves.sh – finds UNFIXED CVEs whose patches can be cleanly applied, useful for building test sets

This methodology ensures verdicts are grounded in ground truth, not just heuristics.

Getting Started

# Set up data repositories
./setup-repos.sh -a -d ../

# Run the checker
./kernel-backport-checker.sh \
    -s ../linux-6.1.1 \
    -d ../linux \
    -e ../kev-data/ \
    -f ../nvd-json-data-feeds \
    -k ../linux-6.1.1/.config \
    -o output

# Or use the binary checker (no source needed)
cd binary-checker
./kernel-binary-backport-checker.sh \
    -b /path/to/vmlinux \
    -d ../linux \
    -e ../kev-data/ \
    -f ../nvd-json-data-feeds \
    -o output

Why This Matters Now

Mitigations alone are not enough. PT3 requires organizations to handle active exploits and potential vulnerabilities properly – to identify, document, remediate, and publicly disclose them. That starts with knowing what you’re exposed to.

Whether you’re a distro maintainer, an embedded vendor using Yocto/AOSP, or a security team auditing your infrastructure, Kernel Backport Checker gives you visibility into the one thing you can’t afford to be blind about: which kernel vulnerabilities are actually fixed in your deployment.