Linux Kernel Recency Matters, CVE Severity Doesn't, and History Fades

TL;DR

This work studies Linux kernel CVEs since the kernel became a CVE CNA, linking vulnerability introduction and patching to commit structure, CVSS metadata, and kernel version age. It employs survival analysis to model time-to-fix and uses PatchScope to annotate commits, revealing that $Y_i = T_{e,i}-T_{s,i}$ is largely insensitive to CVSS vectors and severity, while kernel recency provides a modest predictive signal. The findings show that vulnerability-inducing commits are large and broad, fixes are small and surgical, and newer kernel versions backport patches faster than older ones, with important industry implications for upgrading practices and CVSS usage. The study argues for a shift away from CVSS-based triage in the kernel context and highlights the need for scalable backporting and data-driven vulnerability management in open-source ecosystems. Overall, Linux kernel security dynamics are driven more by development practices and version aging than by externally reported severity scores, a conclusion with direct relevance to industry policy and OSS sustainability.

Abstract

In 2024, the Linux kernel became its own Common Vulnerabilities and Exposures (CVE) Numbering Authority (CNA), formalizing how kernel vulnerabilities are identified and tracked. We analyze the anatomy and dynamics of kernel CVEs using metadata, associated commits, and patch latency to understand what drives patching. Results show that severity and Common Vulnerability Scoring System (CVSS) metrics have a negligible association with patch latency, whereas kernel recency is a reasonable predictor in survival models. Kernel developers fix newer kernels sooner, while older ones retain unresolved CVEs. Commits introducing vulnerabilities are typically broader and more complex than their fixes, though often only approximate reconstructions of development history. The Linux kernel remains a unique open-source project -- its CVE process is no exception.

Figures (4)

• Figure 1: Data collection pipeline in which CVEs and fixing commits are extracted from the kernel repository, vulnerability-introducing commits are identified via line-level blame, commits are mapped to LTS releases, and NVD data is used only for metadata enrichment.
• Figure 2: Distribution of commit sizes by annotation type for vulnerability-introducing (top row) and fixing (bottom row) commits. Each panel corresponds to one annotation type (e.g., code, documentation, tests), and bars are split by change sign: additions (+, green) and deletions (-, red). The x-axis bins commits by the number of changed lines in that type/sign (as indicated by the bin labels). The y-axis reports the percentage of commits in the corresponding class (Vuln/Fix) that fall into each bin (i.e., counts normalized by the total number of commits in the row). Commits with zero or missing changes for a given type/sign are not assigned to any bin and therefore do not contribute to the bars (empty changes are not shown). Note that a single commit may touch multiple annotation types, hence it can contribute to multiple panels; consequently, percentages do not sum to 100% across panels.
• Figure 3: CVSS v3.1 distribution (radar plot) in Linux LTS 5.4 (similar across other LTS branches).
• Figure 4: Survival analysis of CVE fix latency across Linux LTS versions. Newer versions (e.g., 6.12, 6.6) exhibit shorter median fix times compared to older lines (e.g., 5.10, 5.4).