Canonical merges Ubuntu kernel cycles: releases every week
XORit Editorial · Sources, AI assistance and corrections

Canonical has officially announced a transition from the current scheme — a four-week regular cycle plus a separate two-week Ubuntu kernel security cycle (Stable Release Update, SRU) — to a single accelerated two-week cycle. Those releases will be published every week.
The reason is a sharp rise in the number of CVEs. Vulnerability hunting is no longer manual, laborious work: language models and purpose-built AI agents have made it mass-scale and automated. On top of that, the Linux kernel community has itself become a CVE Numbering Authority (CNA) and assigns CVE identifiers to thousands of bugs — the view there is that at the kernel level almost any bug capable of affecting a running system can be treated as a vulnerability.
As a result, CVE volume has grown exponentially, a large backlog of advisories has built up, and the defending side has to speed up fixes sharply to narrow the window of risk.
How the new cycle works: the two-week cycles run in a cascade — each begins a week after the previous one started, so because they overlap, kernel releases come out weekly. The first week is kernel package preparation: selecting updates and patches for specific needs, building, and basic checks that the kernel boots and runs without obvious problems; by the end of the week the builds land in -proposed. The second week is certification testing under the Ubuntu Certified program on various hardware; by the end of it all test artifacts are ready, after which the kernel is released.
Fast releases are incompatible with fully verifying every candidate, so thorough testing is retained. For those who value speed over waiting for certification, release candidates in -proposed are available: they are published before certification begins and updated weekly.
While a patch is being prepared, Canonical aims to provide safe workarounds where they apply. If there is no safe workaround, that is stated plainly, along with general hardening steps. The goal is to bring environments to a protected state within 24–48 hours of a vulnerability's public disclosure, without waiting for the patch: this does not replace the fix, but it buys time to fix things properly.

Translation editors: Соловьев В., Пеков А.
Source: canonical.com ↗