The kernel commit lands. Your fleet is exposed.

Opening Claim

Linux kernel vulnerabilities are disclosed without advance notice to downstream distributions. The kernel security process does not run a coordinated embargo with Debian, Red Hat, SUSE, Ubuntu, or any other distribution maintainer ahead of patch publication. The fix lands in the upstream tree, and from that point the clock starts for everyone equally, including attackers reading the same commits.

This is the operating condition. It is not a bug in the disclosure model. It is the disclosure model. Treat it as a fixed property of the system you depend on, not a temporary gap to be closed by waiting for a vendor advisory.

The operational consequence: the window between upstream commit and downstream package availability is a window in which the vulnerability is public, exploitable, and unpatched on every system you run. The size of that window is not controlled by you. It is determined by how fast each distribution’s kernel team picks up the change, builds, tests, and ships it.

The Original Assumption

Most enterprise patch programs are designed around vendor-coordinated disclosure. The assumption is that a CVE is published alongside a vendor patch, that the vendor had prior notice, and that applying the vendor update closes the exposure on the same day the vulnerability becomes public. This assumption holds for a large portion of commercial software. It does not hold for the upstream Linux kernel.

The assumption extends further in practice. Operators assume that subscribing to a distribution’s security mailing list provides timely warning. They assume that running a supported enterprise kernel means the distribution has been briefed in advance. They assume that the gap between disclosure and patch availability is measured in hours because that is how the rest of their stack behaves.

None of those assumptions are supported by how kernel vulnerabilities reach distributions. The kernel project does not pre-notify distributions as a matter of policy. Patches are merged. Commit messages may or may not flag security relevance. Distributions monitor the same upstream tree everyone else does. Whatever advantage the distribution has comes from staffing and process, not privileged early access.

What Changed

What changed is the visibility of the model, not the model itself. The CVE Numbering Authority status granted to the kernel project formalised what was already true in practice: kernel security fixes flow through normal development channels, and CVE assignment happens after the fact, often in bulk, often for commits that were not labelled as security fixes when they landed. The volume of kernel CVEs has risen sharply as a result. The signal-to-noise ratio for downstream consumers has degraded in the same motion.

For an operator, this means the vulnerability inventory for the kernel cannot be driven by counting advisories. Advisories trail commits. Commits that fix exploitable conditions are not always identified as such at merge time. A patch labelled as a refactor or a stability fix may be silently closing a memory corruption path. The decision of what is security-relevant is made later, by researchers, by distribution security teams, or by attackers who got there first.

The exposure window is therefore not the time between a published CVE and a distribution package. It is the time between the upstream commit and the moment your running kernel image contains that commit. Those are different numbers. The first is what your patch dashboards show you. The second is what determines whether you are exploitable. Any control program that does not measure the second is measuring the wrong thing.

Mechanism of Failure or Drift

The failure mechanism is structural. Upstream commits land in a public tree. Distribution kernel teams ingest those commits on their own cadence, against their own stable branches, with their own build and test pipelines. Each step adds latency. None of those steps begin before the commit is public. The exposure window opens at merge time and closes at package install time on the target host. Every minute between those two events is a minute the fix exists, the diff is readable, and the running system is still vulnerable.

Within that window, the diff itself is the specification for an exploit. A commit that adjusts reference counting, repairs a use-after-free, or tightens a bounds check tells a reader exactly which code path was wrong and how. The reader does not need to find the bug. The reader needs to weaponise the disclosed mechanism against unpatched targets. The asymmetry is direct: the defender waits for a build, the attacker reads the patch. Both started at the same commit. Only one is blocked on a release process.

The drift compounds across the fleet. A single distribution version of the kernel maps to many downstream artefacts: cloud provider images, container base images, appliance firmware, embedded devices, long-lived virtual machines, snapshots restored from backup. Each of those artefacts has its own update path, and several of them have no update path at all without a rebuild or a reboot the operator controls. The patched package existing in a repository is not the same as the patched code executing in a process. Control effectiveness is measured at the running kernel, not at the apt or dnf metadata.

Expansion into Parallel Pattern

The same mechanism appears wherever a control depends on a public source feeding private downstream pipelines with latency. Container base images inherit the same property. The upstream image is rebuilt on a schedule. Every image derived from it carries the unpatched layer until it is rebuilt and redeployed. The CVE scanner reports the base layer as vulnerable. The running container is vulnerable for as long as it runs. The fix exists in a registry. The exposure exists in production.

The pattern holds for any dependency consumed from a public registry where the upstream project does not pre-notify consumers. Language ecosystem packages behave the same way when a maintainer pushes a security fix without an advisory. The commit is public. The release is public. The consumer’s lockfile still pins the vulnerable version until a human or an automated process resolves it. The control that was supposed to be in place, the version pin, becomes the mechanism that holds the exposure open.

In each case the failure is identical in shape. A boundary that was assumed to be enforced by an advisory is in fact enforced by a build pipeline. The advisory is a notification, not a control. The control is whatever rebuilds, repackages, redeploys, and restarts the affected workload. If that pipeline does not exist, or runs slower than the public disclosure cycle, the boundary is not enforced. It is described.

Hard Closing Truth

The upstream Linux kernel does not coordinate disclosure with the distributions you run. That is the system. Any patch program that treats distribution advisories as the start of the exposure window is measuring the wrong event and reporting a window that is shorter than the real one. The real window opens at the upstream commit. The operator does not control when that opens. The operator controls only how fast the running kernel can be replaced after it does.

What must now be true: the time from upstream kernel commit to running kernel image must be measured, owned, and bounded. Not the time to package availability. Not the time to advisory publication. The time to the kernel actually executing on the host. If that number is not instrumented, it is unknown, and an unknown exposure window is an uncontrolled one. Live kernel patching, automated reboot orchestration, and image rebuild pipelines exist because this is the only number that determines whether the control held.

Controls that are not enforced are not controls. Waiting for a vendor advisory on a kernel CVE is waiting on a notification that arrives after the exposure has already begun. The boundary is the running kernel. The enforcement is the rebuild and restart cycle. Everything else is reporting.