Why Linux Distros Are Always the Last to Know About Kernel Vulnerabilities

Spend any time watching Linux kernel security and you’ll notice something odd. A fix lands in the mainline kernel, but Ubuntu, Debian, and RHEL — the distros that ship that kernel to millions of machines — don’t catch on for days. Sometimes weeks. So much for “open source means faster and more transparent.” Today let’s unpack why the Linux disclosure chain keeps grinding its gears.

Yes, There’s a Mailing List. No, It Doesn’t Cover Everything.

The Linux ecosystem has a private mailing list called linux-distros. When a vulnerability surfaces, it’s shared with major distro maintainers ahead of public disclosure so they can prep patches behind an embargo. On paper, clean. Researcher reports a bug, embargo gets set, distros all ship fixes on the same day. Coordinated disclosure 101.

The problem is what doesn’t get routed through it. If a kernel maintainer triages a flaw as a regular bug and merges the fix, it lives as a plain old git commit. No security label. No linux-distros notification. The fix is public, but the signal that says “you should care about this one” never reaches downstream.

The Gray Zone of “Looks Like a Bug, Acts Like a Vulnerability”

Greg Kroah-Hartman and other core kernel maintainers have held a consistent line for years. Every bug fix is potentially a security fix. Therefore, don’t bother labeling things separately.

There’s a real argument here. You usually can’t tell upfront whether a memory-safety bug is actually exploitable. And once you start tagging some commits as “security,” you implicitly tell everyone the unlabeled ones are safe — which is a lie. Fair enough philosophically. The catch is operational. Distro security teams are tiny, and the kernel produces hundreds of commits a week. Nobody is hand-reading all of them. So the steady state is: the kernel is fixed, the distro has no idea.

The CVE Firehose Made It Worse

In 2024 the kernel team became its own CVE Numbering Authority and started issuing CVEs directly. Well-intentioned. The result, though, is that the kernel now pumps out dozens of CVEs per week, many of them low-severity or only relevant to obscure configurations.

Distro maintainers now have a worse signal-to-noise problem than before. When everything is a CVE, nothing is a priority. Some get patched into stable trees within days. Others get filed and forgotten. And the question of who tells downstream distros, when, and through what channel still hasn’t been formalized inside this new structure.

The Real Risk: Patch-Gap Exploits

For attackers, this gap is a gift. The kernel git tree is fully public. When a security-impacting commit lands, anyone can read the diff, study the commit message, and work backward to an exploit. This is the well-known “patch-gap exploit,” and Project Zero has been writing about it for years.

The window between mainline merge and a backported fix reaching users runs from a few days to several weeks. That’s the unguarded zone. When pre-disclosure coordination fails, the zone widens. For a cloud provider running tens of thousands of Linux instances, this isn’t an abstract governance issue — it’s an attacker’s calendar.

So What’s the Fix?

There isn’t a clean one. Asking maintainers to security-classify every patch isn’t realistic. Asking every distro to staff a bigger security team isn’t either. The conversation is increasingly turning toward middle-layer automation: machine-learning classifiers that scan kernel commits and surface the ones likely to have security impact. Google and a few research groups have prototypes in this space.

But the deeper issue is governance. Who decides Linux’s security policy, and how do those decisions propagate downstream? That answer is still hand-wavy. In an era where Linux runs essentially every cloud, every container, and most of the embedded world, kernel disclosure isn’t one project’s problem anymore. It’s an ecosystem problem.

The Takeaway

Linux’s superpower has always been openness. In security, that same openness cuts both ways. Anyone can read the patch, which means anyone can reverse-engineer the bug. The kernel running your production fleet right now is sitting inside some patch gap — the only question is how wide. Worth asking before someone else does.