CONCEPT Cited by 1 source

LTS kernel backport latency gap¶

The LTS kernel backport latency gap is the structural window between when a Linux kernel fix lands in mainline and when it reaches the Long-Term Support (LTS) series that a production operator actually runs. Even an operator with a best-in-class biweekly patching cadence can remain vulnerable to a public CVE because the upstream fix — merged to mainline weeks earlier — has not yet been backported to the LTS line their fleet runs. Canonical wiki articulation from the 2026-05-07 Copy Fail response post, where Cloudflare explicitly named the gap as the reason their fleet remained vulnerable despite their standard patching discipline.

The load-bearing verbatim¶

From the post's conclusion paragraph:

"The 'Copy Fail' vulnerability presented a unique challenge for us. Despite our practice of deploying Linux patch updates every two weeks, we remained vulnerable because a month-old mainline fix had yet to be backported to our primary kernel line."

Two orthogonal tempos in play:

Cloudflare's internal build + deploy cadence — approximately biweekly kernel patch rollout through ERR.
Upstream LTS backport cadence — driven by the community LTS maintainers; not under the operator's control; varies per LTS series and per-patch priority.

The gap is entirely the second tempo: the operator can't patch what the LTS hasn't received.

Structural properties¶

Mainline → LTS backport isn't automatic. Upstream mainline merges are the source of truth; LTS maintainers review and selectively backport patches to each supported LTS series. Backport latency depends on maintainer workload, patch complexity, and priority.
Public disclosure often happens before LTS backport lands. Coordinated disclosure tries to align with LTS availability, but the Copy Fail case shows this isn't guaranteed — the fix was a month old in mainline but not yet in LTS 6.12 on 2026-04-29.
Biweekly patching doesn't close the gap. Cloudflare explicitly frames this: their biweekly deploy cadence operates over whatever the LTS feeds them. Faster internal build + deploy → no help if the LTS hasn't emitted the patch yet.
Different LTS series have different gaps. At Copy Fail disclosure Cloudflare's majority ran 6.12, a subset ran 6.18. The 6.12 backport was the blocker; a 6.18 backport may have had different timing.
Multiple LTS lines in flight amplify risk. An operator running multiple LTS series simultaneously must track backport status per-series and may be patched on one series but not another.

What closes the gap¶

Three non-overlapping levers:

Runtime mitigation — bpf-lsm programs that gate the vulnerable kernel code path at an LSM hook. Cloudflare's canonical answer for the Copy Fail window. Ships in hours, no reboot, covers the majority LTS line until the backport arrives.
Attack-surface reduction at build time — remove unused modules / features from the custom kernel build entirely, so CVEs in those subsystems don't apply to your fleet in the first place. Stated Cloudflare follow-up: "Reduce attack surface of Linux Kernel. Review and audit our kernel configuration. Proactively identify unused modules or features so that we can remove them from our build entirely." Structural, not tactical.
Accelerated LTS migration under pressure — ship the next LTS series (6.18 in Copy Fail's case) to the fleet ahead of normal cadence. Cloudflare explicitly did not do this for Copy Fail (decision 2026-04-30 ~17:00 UTC: "ship a patched build of the previous LTS line through reboot automation; do not accelerate the new LTS; lean on bpf-lsm in the meantime"). The stated reason is that accelerating a major LTS migration under incident pressure introduces its own risk; better to close the window with runtime mitigation and migrate LTS on the normal long-cycle timeline.

Why biweekly cadence is insufficient¶

Naive reasoning: "we patch every 2 weeks, so any CVE older than 2 weeks is covered." This is structurally wrong because:

The 2-week window is from internal build to fleet deployed — not from mainline merge to fleet deployed.
Mainline → LTS backport adds days to weeks on top of the internal tempo.
Disclosure timing can land the CVE inside the backport window, so the operator is running a kernel that never received the fix — even though the fix has been public for weeks.

The Copy Fail case makes this concrete: mainline fix was a month old at disclosure; Cloudflare's LTS 6.12 build hadn't received it; biweekly patching didn't help.

Seen in¶

2026-05-07 — Cloudflare Copy Fail response. Canonical wiki first-class page. Cloudflare's explicit self-assessment that "despite our practice of deploying Linux patch updates every two weeks, we remained vulnerable because a month-old mainline fix had yet to be backported to our primary kernel line." Runtime mitigation via bpf-lsm closed the window; the patched LTS 6.12 build flowed through ERR once the backport landed on 2026-04-30. (Source: sources/2026-05-07-cloudflare-copy-fail-linux-vulnerability-response)