{"id":"27dc443e-b50d-42c7-9ee6-28931bff85a0","arxiv_id":"2601.22196","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Linux kernel CVE fix speed is unrelated to CVSS severity scores, but newer kernel branches are patched faster than older ones.","lead":"This paper studies thousands of Linux kernel security warnings (CVEs) created after the kernel project took over CVE management in 2024. It finds that severity scores do not predict how quickly flaws get patched, while newer kernel versions are patched faster than older ones.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The §5.5 recency gradient may be an artifact of CVE-population composition across LTS branches; a within-CVE comparison is missing and should be required.","rationale":"The paper's most valuable and actionable claim is RQ3: kernel version age predicts fix latency. Its evidence is entirely a marginal comparison of survival curves across LTS branches. Because each LTS branch observes a different, non-random slice of the CVE population, the gradient could be generated by differences in which CVEs reach each branch rather than by any behavioral difference in patch speed. This is a classic composition/left-truncation confound, and the manuscript neither stratifies by CVE nor restricts to common support. Section 3 and Section 5.2 explicitly flag the dyad approximation and the 2005 import commit, but the branch-composition problem is not acknowledged in Threats to Validity. The import-commit artifact is real, but it primarily affects the absolute lifetimes and the RQ1 commit-size asymmetry (e.g., Table 3's 204,645 added lines), not the rank-based branch gradient; it still merits a sensitivity check. The CVSS null result (Table 5) is robust—the associations are near zero with tight confidence intervals, and the within-population comparison makes it less vulnerable to composition bias. The proposed within-CVE stratified Cox model and common-support D_xy is a single, feasible check that would settle whether the recency claim is causal or compositional. The reader's conditional verdict already asks for controls; I agree, and would make the within-CVE comparison an explicit part of the condition. Therefore the verdict should remain CONDITIONAL/UNCHANGED, but with this concrete robustness check made mandatory.","tokens_in":19701,"tokens_out":11466,"duration_ms":128771,"concrete_test":"Restrict the survival analysis to CVEs that are observed in at least two (ideally all six) LTS branches, and recompute per-branch medians, Kaplan–Meier curves, and D_xy with LTS version as the ordinal predictor. In the same subset, fit a Cox proportional-hazards model with CVE ID as a stratification factor (or a fixed effect), estimating the branch-age effect within each CVE. If the within-CVE effect remains positive with D_xy ≈ 0.13, the recency finding survives; if it collapses toward zero or reverses, the §5.5 gradient is a composition artifact. Additionally, rerun the time-to-fix tables excluding all observations whose dyad-inferred introducing commit is 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, to quantify how much of the absolute medians depend on the 2005 import snapshot.","verdict_should_be":"UNCHANGED","load_bearing_attack":"For RQ3, the analysis compares marginal survival distributions of time-to-fix across six LTS branches (§5.5, Table 6, Fig. 4). Each observation is a (LTS, CVE) pair, so the same CVE appears in multiple branches. But the set of CVEs assigned to a branch is not randomized: a CVE appears in a branch only if the vulnerable code exists there and the fix is backported after that branch was created, otherwise the branch would not contain the flaw. Thus newer branches (6.12, 6.6) are systematically enriched for recently introduced or recently fixed flaws and for code that survived into those releases, while older branches (5.4, 5.10) include long-lived flaws in old subsystems that never carried forward. The reported median gradient (1,112 days in 6.12 vs. 2,677 days in 5.4) and D_xy=0.13 conflate 'newer branches are patched faster' with 'the CVE populations differ.' Section 3 acknowledges that dyad-inferred introduction timestamps are approximations, and Section 5.2 notes that the 2005 BitKeeper-to-Git import commit (1da177e4c3f41524e886b7f1b8a0c1fc7321cac2) distorts many CVE associations, but no analysis quantifies either artifact. The paper never stratifies by CVE ID or restricts to CVEs observed in multiple branches, and Threats to Validity does not mention branch-composition confounding. The practical conclusion—'move to newer kernels for faster fixes'—depends on a causal reading of this gradient, making composition confounding the most load-bearing concern. The CVSS null result is much less affected because it compares within similar populations and the associations are near zero.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper analyzes 6,464 Linux kernel CVEs issued since the kernel became its own CNA, combining NVD metadata, kernel commit data, dyad/strak/verhaal tooling, and survival analysis to answer three RQs. RQ1 finds that vulnerability-introducing commits are substantially larger and more heterogeneous than fixing commits. RQ2 reports that CVSS v3.1 metrics and severity levels have a negligible association with fix latency, with Somers' D approximately zero. RQ3 reports that newer LTS branches are associated with shorter fix times, with D_xy = 0.13 and median fix times rising from 1,112 days in 6.12 to 2,677 days in 5.4. The paper concludes with practical recommendations to move to newer kernels and not to rely on CVSS for triage.","tokens_in":20048,"tokens_out":8284,"duration_ms":96297,"significance":"If the results hold, this is one of the first large-scale quantitative studies of the Linux kernel CNA era, and the replication package and CVE-commit mappings are valuable community assets. The survival-analysis framing and the CVSS negative result are useful contributions. However, the most practically consequential claim — that kernel recency drives fix speed — is currently supported only by a marginal, cross-sectional comparison across LTS branches, and the CVSS null result is limited by severe vector imbalance and non-random missingness. The paper needs additional within-CVE and sensitivity analyses before the policy-level recommendations are warranted.","major_comments":[{"comment":"The RQ3 result is computed on the marginal distribution of time-to-fix across (LTS, CVE) observations. Because a CVE appears in a branch only when the vulnerable code is present and the fix is backported to that branch, the six branch populations are not exchangeable: 6.12 and 6.6 are enriched for recently introduced or recently fixed flaws, while 5.4 and 5.10 include long-lived flaws that were never carried forward. The reported gradient (median 1,112 vs 2,677 days; D_xy=0.13) therefore conflates branch age with CVE composition, and Section 7 does not mention this threat. I request a within-CVE analysis: for CVEs observed in multiple branches, compare fix times in the newer and older branches (paired differences or stratified survival), and report the gradient restricted to a common introduction-era cohort. Without this, the Section 8.1.1 recommendation to \"move to the latest kernel ver","section":"§5.5, Table 6, Fig. 4"},{"comment":"The start time T_s comes from dyad-inferred introducing commits, and the paper itself states these are approximations affected by squashing and pre-Git history. The footnote in §5.2 says many CVEs are associated with the 2005 BitKeeper-to-Git import commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, which \"distorts many CVE associations.\" This is not a minor caveat: every branch in Table 6 has max time-to-fix 7,396 days, equal to the interval from that commit to the study end, indicating that a substantial number of observations are anchored to this one commit. I ask the authors to (i) report how many LTS-CVE observations have T_s = 1da177e, (ii) re-run Table 6 and D_xy with those observations excluded, and (iii) include this as an explicit sensitivity analysis in Section 7.","section":"§3, §5.2, Table 6"},{"comment":"The severity-null conclusion is stated as \"negligible association,\" but the test has limited sensitivity on this dataset. Only 43% of LTS-CVE pairs have CVSS metadata, and coverage varies strongly by branch (31% for 6.12 vs 62% for 5.4, Table 1), so missingness is not random. Moreover, §5.3 shows that >95% of vectors follow one template; Somers' D on such an imbalanced ordinal predictor cannot detect non-monotonic or threshold effects. The significant log-rank results are dismissed without reporting the magnitude or direction of the differences other than the near-zero D. I recommend softening the title/RQ2 claim to \"no monotonic association is detectable in the current data\" and adding an analysis that conditions on the dominant vector combination or uses regression with clustered standard errors.","section":"§5.4, Tables 1 and 5"}],"minor_comments":[{"comment":"The confidence intervals are reported as [-0.0,-0.0] or [-0.01,-0.01]; please report raw Somers' D values to at least three decimal places and state the number of comparable pairs used for each metric.","section":"Table 5"},{"comment":"Because one commit can contribute to multiple annotation panels, the caption should state explicitly that the bars do not sum to 100% across panels; currently this is only implied in a parenthetical.","section":"Figure 2"},{"comment":"The log-rank robustness check is mentioned in the text but the test statistic, degrees of freedom, and p-values are not reported, and the method is not described in Section 3. Add details or remove the reference.","section":"§5.4"},{"comment":"The spot check is described as 20 random large commits plus 3 added edge cases. Please report how the 3 additional commits were selected and whether any of the 20 were excluded after review, so readers can assess the generalizability of the qualitative findings.","section":"§5.2"},{"comment":"The 'Unique CVE' column counts the same CVE in multiple LTS rows; this should be stated in the caption to avoid the impression that the rows are disjoint.","section":"Table 1"},{"comment":"The text calls the gradient a \"simple interpretation\" of Section 5.5. This should be explicitly tied to the within-CVE analysis requested above; as written it reads as endorsing a causal interpretation of a cross-sectional comparison.","section":"§8.1.1"}],"recommendation":"major_revision","confidential_remarks":"The paper has a strong, reusable dataset and an interesting negative result on CVSS, but the recency gradient — the paper's headline practical message — is currently vulnerable to CVE-population composition and the 2005 import-commit artifact. I would not accept before a within-CVE/paired analysis and a sensitivity analysis excluding the import commit are added. The revision is feasible within the paper's scope and would substantially strengthen the contribution."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"First: the CVSS null result is the real finding. Across 6,464 CVEs since the kernel became its own CNA, no CVSS v3.1 base metric or severity level consistently predicts fix latency; Somers' D is near zero with tight bootstrap CIs. That is a clean, useful negative result for security teams. Second: the recency gradient in §5.5 (newer LTS branches fix faster, D_xy=0.13) is plausible but under-supported. The paper compares marginal survival distributions across branches, and the CVE populations in those branches are not exchangeable. A CVE appears in a branch only if the vulnerable code exists there and the fix is backported; newer branches are enriched for recently introduced or recently fixed flaws, older branches for long-lived flaws that didn't carry forward. So the median gradient conflates branch age with CVE composition. A within-CVE analysis—stratify by CVE ID, or restrict to CVEs observed in multiple branches—would settle whether the gradient is causal or compositional. The paper doesn't do that, and Threats to Validity doesn't mention it. That's the load-bearing gap.\n\nWhat's new and good: first survival analysis of kernel CVEs after the kernel became CNA; a decent-sized curated dataset with replication package; appropriate use of censoring and bootstrap; a manual spot check of large inducing commits that gives useful qualitative context. The commit-anatomy finding—fixes are small and surgical, inducing commits are broad—is descriptive and interesting, though dependent on dyad's inferred introduction points. They acknowledge the approximations, and the 2005 BitKeeper-to-Git import commit is mentioned as an outlier, but it isn't excluded in the quantitative commit-size comparisons, which likely inflates those medians. That is a moderate concern for RQ1, minor for the paper as a whole.\n\nWho should read this: security practitioners deciding whether to trust CVSS for kernel triage, and MSR audiences interested in survival analysis of vulnerabilities. It deserves a serious referee. I'd send it to review, and the main ask would be: add the within-CVE stratified analysis for §5.5, and run a sensitivity analysis dropping the import commit from the commit-size stats. If those come back consistent, this is a solid publishable paper. If the gradient disappears, the abstract's 'kernel recency matters' claim needs to be pulled back.","headline":"CVSS null result is solid; the recency gradient in §5.5 needs a within-CVE control before you can trust it.","tokens_in":20605,"tokens_out":2340,"would_cite":true,"duration_ms":24476,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"For Linux kernel CVEs, how new your kernel is predicts how fast it gets fixed; CVSS severity has no measurable effect.","keywords":["Linux kernel","CVE","CVSS","survival analysis","patch latency","LTS kernels","vulnerability-introducing commits","backporting"],"falsifier":"Manually audit a random sample of, say, 100 CVE-introducing commit mappings using mailing-list history or bisection, then re-estimate median fix times on the corrected subset. If the median ordering across LTS branches flips or the gap between 6.12 and 5.4 collapses below, say, 500 days, the recency claim is an artifact of the mapping. Separately, if a dataset with balanced CVSS scores (not the near-constant current vectors) still shows no association with fix latency, the severity claim is corroborated; if not, it is refuted.","tokens_in":19611,"feed_emoji":"🐧","tokens_out":5920,"duration_ms":55986,"temperature":0.7,"pith_summary":"Since the Linux kernel became its own Common Vulnerabilities and Exposures (CVE) Numbering Authority in 2024, the project has issued an order of magnitude more CVEs, making systematic study possible. Using 32,857 (LTS-branch, CVE) observations across six long-term support kernels, the paper shows that CVSS v3.1 base metrics and severity levels have essentially zero association with how long a vulnerability takes to fix (Somers' D ≈ 0), while kernel branch version age is a consistent, modest predictor: median fix time rises from about 1,112 days on the newest branch (6.12) to 2,677 days on the oldest (5.4). The paper also finds that vulnerability-introducing commits are typically far larger and broader than their fixes, and that many are squashed or refactored histories whose true introduction points have faded. A sympathetic reader would take this as an empirical confirmation that triaging kernel CVEs by CVSS score is ineffective, and that remaining on old LTS branches carries a measurable security cost.","feed_headline":"Kernel recency, not CVSS severity, sets CVE fix speed","feed_subtitle":"Median fix time is 1,112 days on the newest LTS branch and 2,677 on the oldest; CVSS scores are near-zero predictors.","key_machinery":"The analysis is carried by survival analysis: Kaplan-Meier survival curves estimate the probability that a CVE remains unfixed at time t, and Somers' D (a rank correlation for censored data) quantifies the association between a predictor and fix time, with bootstrap confidence intervals. The time axis is measured from the inferred vulnerability-introducing commit to the earliest fixing commit in each LTS branch, where introducing commits are inferred by a dyad-based tool and fixing commits by pattern matching in the kernel's CVE repository. Commit anatomy is annotated line-by-line by PatchScope into code/documentation/configuration/test categories. These together turn a heterogeneous CVE dat","core_discovery":"The central discovery is a dissociation between two factors commonly assumed to drive patching. Across all CVSS v3.1 vector components and severity levels, Somers' D with time-to-fix is effectively zero with very narrow bootstrap confidence intervals, so severity does not predict fix latency. In contrast, the LTS branch's position in the kernel's release sequence does predict fix latency, with Somers' D = 0.13: median fix time is 1,112 days in branch 6.12, 1,427 in 6.6, 1,844 in 6.1, 1,960 in 5.15, 2,189 in 5.10, and 2,677 in 5.4. The authors also show that introducing commits are structurally larger (median 2 files, 56 added lines) than fixing commits (median 1 file, 4 added lines), and tha","pith_inferences":["If the kernel CNA ever assigned CVSS scores itself rather than inheriting NVD templates, the near-zero association could change; the paper's own association-rule analysis shows the current vectors are almost constant, so the severity result may reflect template uniformity rather than a true indifference to severity.","The recency gradient could be partly explained by maintenance effort being concentrated on branches that serve more users; D = 0.13 leaves substantial room for other drivers such as subsystem maintainership and backport difficulty.","A practical test the paper implies but doesn't run: compare fix latency between CVEs of the same age but different architecture or subsystem; if subsystem explains more variance than branch age, the 'move to latest' recommendation could be refined into 'move to well-staffed subsystems.'","The 2005 import commit artifact affects all branches similarly, so the relative gradient likely survives its removal, but absolute lifetime numbers should be read as upper bounds for true vulnerability age."],"forward_implications":["Organizations running older LTS kernels (5.4, 5.10) should expect known CVEs to remain unfixed for roughly 2,000-2,700 days on median, versus about 1,100 days on 6.12, so kernel version choice is a security parameter.","CVSS base scores and severity levels are not informative for prioritizing Linux kernel patches; decisions based on them are unlikely to reduce exposure.","The backlog of ~14 new kernel CVEs per day, combined with slow backporting to old branches, makes automated backporting and upstream-first strategies increasingly necessary.","Because introducing commits are large and often squashed, forensic estimates of vulnerability age are inherently approximate; bug-introduction data should be treated as a reconstruction, not a ground truth.","When a root cause is known, fixes tend to be tiny (≤9 lines in 75% of cases), so the practical bottleneck is detection and coordination, not patch size."],"fun_headline_variants":["CVE fix time hinges on kernel age, not severity score","Newer kernels get patched faster, severity irrelevant","Linux CVE patch speed: recency wins over CVSS","Kernel line's age predicts CVE fix speed, severity doesn't","Severity scores don't drive Linux CVE fixes; kernel recency does"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The whole time-to-fix measurement rests on the dyad-inferred vulnerability-introducing commit being the true moment a vulnerability entered the code; squashed commits, refactorings, and the 2005 BitKeeper-to-Git import can shift these dates, and the paper does not quantify how much bias that introduces.","fun_headline_variants_meta":{"raw":{"variants":["CVE fix time hinges on kernel age, not severity score","Newer kernels get patched faster, severity irrelevant","Linux CVE patch speed: recency wins over CVSS","Kernel line's age predicts CVE fix speed, severity doesn't","Severity scores don't drive Linux CVE fixes; kernel recency does"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000155,"raw_usage":{"total_tokens":1041,"prompt_tokens":723,"completion_tokens":318,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":467,"completion_tokens_details":{"reasoning_tokens":229}},"tokens_in":467,"tokens_out":318,"duration_ms":3619,"temperature":1.0,"reasoning_tokens":229,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-03T06:52:51.274111+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Manually audit a random sample of, say, 100 CVE-introducing commit mappings using mailing-list history or bisection, then re-estimate median fix times on the corrected subset. If the median ordering across LTS branches flips or the gap between 6.12 and 5.4 collapses below, say, 500 days, the recency claim is an artifact of the mapping. Separately, if a dataset with balanced CVSS scores (not the near-constant current vectors) still shows no association with fix latency, the severity claim is corroborated; if not, it is refuted.","supporting_citations":[],"review_version":1}