Linux Kernel Security: The Kernel Went Weekly Because the Machines Started Finding Bugs
In 1994 I compiled my first Linux kernel from a c't magazine cover disc, a copy of Slackware 1.1.2. It was on a 486 I was not allowed to touch again until it finished. Twenty-eight hours later, it booted. I did not make that faster by wanting it to. The machine took exactly as long as it took. The only honest thing to do was leave it alone and let the work finish. I did not know it then. That patience set the pattern. Software freedom always costs something, in time, attention or money. The bill just moves to wherever the next bottleneck sits that decade.
Canonical just told its own version of that story, in reverse. On 28 September 2026, Ubuntu folded its two separate kernel update schedules into one. A four-week cycle covered routine fixes; a two-week cycle covered security. The new, overlapping two-week cycle lands a kernel roughly every seven days [1][2]. A flood of work sits behind that change, more than the old schedule could absorb. No machine runs any faster for it.
Canonical says so in its own words. Security researchers running "large language models (LLMs) and specialised AI agents have transformed bug discovery" from something a small team did by hand into something that now runs continuously [1]. At the same time, the upstream kernel community decided to become its own CVE Numbering Authority. Thousands of bugs that used to sit unlabelled now carry a formal identifier [1]. More bugs are being found, faster, and more of them now carry an official number. That review queue was never built for this volume.
Being your own CVE Numbering Authority is not a ceremonial title. It means the kernel security team, rather than a third party, decides which reported flaws are serious enough to carry a public identifier, and does so on its own clock. Before this year, plenty of real kernel bugs went unlabelled. That made them easier to miss and harder to prioritise against everything else competing for a maintainer's time. Assigning identifiers faster does not make the underlying bugs disappear. It makes the backlog visible in a way it was not before. That visibility is its own kind of pressure.
Look at what Canonical actually changed, and what it did not. The new cadence keeps the full two weeks of work behind every release. Week one is patch integration, packaging, build and smoke testing. Week two is certification and regression testing through Ubuntu's certified hardware programme, with release candidates available ahead of full certification. Nothing in that sequence got shorter. What changed is that two of those two-week cycles now run in parallel instead of in sequence. A finished kernel now lands roughly every week instead of every two to four. Canonical's own target for a serious vulnerability is "a defensible, safer state within 24 to 48 hours of public disclosure" [1]. That target is met by running more of the same careful process at once, not by cutting any of it. Two teams, offset by a week, can run the same fourteen-day process without either one rushing. The discipline that used to apply once a month now applies every single week. That costs more total effort across the organisation, not less.
I read Eric Raymond's "The Cathedral and the Bazaar" in 1998, while I was Technical Services Manager at ICONZ. It did not teach me something new. It gave a name to a practice I was already living: release early, release often, and let enough eyes catch what one pair would miss [4]. Canonical's answer to the AI-driven bug flood is a plain expression of that same bazaar instinct. Faced with more eyes finding more problems than the old queue could clear, the response was not a machine that clears the queue instead of people. Canonical just ran the same process twice as often instead.
systemd answered a smaller version of the same pressure with something closer to a social contract than an engineering fix. The project's contributor instructions for AI coding agents sit in a file called AGENTS.md. It tells any agent touching source code to add a short banner to its own pull request: "Remove this line to confirm you've reviewed this PR before submitting" [3]. The agent is told never to remove that line itself. Only a human who has actually read the change is supposed to delete it.
AGENTS.md also closes the obvious workaround: an agent asked to "clean up" or "finalise" the pull request is still bound by the same rule, and may not use either request as an excuse to remove the banner itself [3]. It is a small mechanism. It does not stop an agent that never opens AGENTS.md, and it does not catch a human who deletes the banner without reading anything behind it. What it does is make the absence of review visible instead of invisible. A faster scanner or a stricter merge gate would not do that. Canonical lengthens the process without shortening it. systemd puts a flag on the process so an outsider can tell whether anyone actually walked through it. Neither project built a machine to replace the reviewer. Both admitted, in their own engineering language, what the reviewer actually is. The reviewer is the part of the system that was never going to scale on its own.
Thirty-two years into this series' running argument about the Cathedral and the Bazaar, this is a genuinely new axis for the same old claim. The bazaar has always said that enough eyes make bugs shallow. Nobody arguing that case in the 1990s had to ask what happens when the number of things needing eyes grows faster than the number of eyes available. Canonical and systemd, independently and a few days apart, both answered that question this year. Neither answer involved a machine doing the looking.
This is the same pattern the series keeps finding underneath Andrew Tanenbaum's old argument with Linus Torvalds. The argument was over whether a kernel should be elegant first or working first. Worse is better because working code gets reviewed by more people than a theoretically correct design nobody can run yet. Canonical and systemd have found the version of that argument that applies when the thing needing review arrives faster than any theory anticipated.
For a team running Ubuntu in production, the lesson is not to panic at a bigger CVE count. Canonical's own kernel team has said for months that the number that matters is the intersection of what gets patched against what you actually run. The raw count tells you nothing on its own. The practical response to a weekly cadence is to know your own kernel configuration well enough to answer that question quickly. Build the 24-to-48-hour workaround window into your own incident runbook. Do not wait to discover it during an actual disclosure. That means keeping an accurate list of which kernel subsystems your own workloads actually touch. A published flaw in, say, a filesystem driver you have never loaded then becomes a line you can close in minutes rather than an afternoon of investigation. It also means treating Canonical's -proposed release candidates as something your test environment watches routinely, not something you discover exists the week a disclosure lands. None of this is new discipline. It is the same patch-management hygiene that mattered at a four-week cadence, now run on a tighter clock.
The same discipline applies if your own organisation is letting AI agents touch code. Do not ask whether the agent is fast. Ask whether it is possible to tell, afterwards, that a person actually looked at what it wrote. systemd's banner is one cheap way to do that. Pick your own version of a mark that a human, not a model, has to remove. Treat its absence as a blocked merge rather than a formality. Log who removed it, and when, the same way you would log who approved a production change. The banner is only worth anything if someone is willing to ask the question it exists to raise.
The open-source dimension of this one barely needs building, because it is the whole story rather than a lesson drawn from the margins of it. The kernel community's decision to become its own CVE Numbering Authority is a community choosing to run its own disclosure process. It chose not to wait on an outside body to assign one. systemd's AGENTS.md sits in the open repository, where anyone can read it or fork it. A proposal to remove the review banner is as visible, and as answerable, as the rule itself. Neither mechanism is a vendor's internal policy memo. Both are the bazaar's usual answer to strain: publish the rule, and let the whole community see whether it holds.
Defence and allied procurement have been here before, on a smaller scale. Heartbleed, the 2014 flaw in OpenSSL, sat undiscovered for two years inside software securing a large share of the internet's encrypted traffic. At the time, it was maintained by a handful of volunteers. What mattered was the funding that followed, channelled through the Linux Foundation's Core Infrastructure Initiative, aimed at paying for ongoing maintenance and review capacity rather than for one more emergency release [5]. Canonical and systemd have reached a similar conclusion a decade on, at a different scale and against a different kind of flood. When the constraint is a person's attention rather than a line of code, the answer is to fund or organise more of that attention. It is not to wait for a faster machine to make the shortage disappear.
You once spent twenty-eight hours unable to touch a 486, because that was how long the work took. Later, you managed a technical services team at ICONZ through its own version of too much coming in at once. Canonical and systemd have just admitted, in their own engineering language, that the real constraint on an AI-accelerated kernel is still a person's attention, not the machine. If someone handed you an AI agent tomorrow that could triage bugs ten times faster than any team you have run, what is the first thing you would refuse to let it touch? Not because it could not do the work, but because nobody would be able to tell whether it had.
This is one of seven weekly series in The Hamberger Report. Subscribe on LinkedIn and the next one arrives in your feed.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. I write as director of Te Pono Limited; the views are personal and do not represent the position of any client, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance, and it is politically neutral.
About the Author: Andreas Hamberger is a New Zealand-based enterprise architect and technology strategist. Over 30 years, he has moved from compiling kernels on a 486 to leading cloud, cyber, and AI transformation programmes across government, banking, transport, and aviation. He founded Yoper Linux, served as a technology specialist for Novell during the Linux Wars, and is the author of "Generative AI: Skynet or Heaven" and "Space Mafia." A Concise History of Linux chronicles the operating system that changed the world and the lessons it holds for the AI era. He can be reached at andreas@thehambergerreport.com.
This article was produced with AI assistance under my direction. Research, drafting and images pass through a pipeline I built and govern: automated gates for source verification, forbidden language and political neutrality, and my own review before anything is published. The tools include Claude, Gemini and Openart. The frameworks, arguments and editorial judgements are mine and are the same discipline I apply to the AI systems I audit for clients. AI accelerated the work; the thinking, and the responsibility for it, are mine.
[1] Canonical. "Accelerating delivery of CVE fixes with a new kernel release strategy." 23 September 2026. URL: https://canonical.com/blog/accelerating-delivery-of-cve-fixes-with-a-new-kernel-release-strategy
[2] The Register. "CVE flood pushes Ubuntu onto weekly kernel release cycle." 24 September 2026. URL: https://www.theregister.com/os-platforms/2026/09/24/cve-flood-pushes-ubuntu-onto-weekly-kernel-release-cycle/5298912
[3] systemd Project. "AGENTS.md." systemd/systemd repository, main branch. Accessed 1 October 2026. URL: https://raw.githubusercontent.com/systemd/systemd/main/AGENTS.md
[4] Raymond, Eric S. "The Cathedral and the Bazaar." First presented 27 May 1997; published 1999.
[5] The Register. "Bevy of tech behemoths aim to plug the next Heartbleed with dollars." 24 April 2014. URL: https://www.theregister.com/2014/04/24/linux_foundation_core_infrastructure