-proposed pocket after about a week, but those builds have not yet gone through Canonical's certification testing. The reason is volume: Canonical says AI-assisted bug hunting and the Linux kernel's own CVE assignment policy have produced more vulnerabilities than its old schedule can handle. For anyone running Ubuntu at scale, patching becomes a weekly job, and each team now has to decide how much testing it will do itself in exchange for speed.
Canonical folds Ubuntu's 4/2 kernel SRU cadence into one weekly release train
Canonical's announcement describes a transition from its current 4-week regular and 2-week security kernel Stable Release Update (SRU) cycles to a unified, rapid 2-week SRU cycle, published weekly. The Register first reported the change. Help Net Security, OMG! Ubuntu and Linuxiac have covered it independently since, and all of them describe the mechanics the same way.
Canonical's kernel documentation explains the model being replaced. Since August 2023, the Ubuntu Kernel team has adopted a 4/2 Kernel SRU cycle to improve predictability and responsiveness. It involves a 4-week ("4/") stable update cycle for regular fixes and features, combined with an additional mid-cycle 2-week ("/2") update focused on urgent CVE security patches and critical fixes. According to OMG! Ubuntu, the 4/2 schedule was introduced in 2023 after criticism in how it long it took to roll out patches for Zenbleed. So this is the second time in three years that Ubuntu's kernel cadence has been sped up in response to security pressure.
Under the new model the two separate tracks become one. Each cycle still lasts two weeks, but a new one starts every week. Linuxiac points out that this does not mean Canonical is reducing the full kernel testing process to seven days. A new two-week cycle starts every week, allowing one kernel to be in its final testing stage while the next is already being prepared.
The switch happens in stages. On Ubuntu's Discourse forum, the kernel team says it will be initially transitioning to 2 back to back 2-week cycles starting 2026.09.28 and 2026.10.12. Those two cycles run one after the other without overlapping. Working from the dates, the first overlapping cycle, and so the first truly weekly releases, should start in late October once the second cycle ends.
Two overlapping two-week cycles keep the weekly Ubuntu kernel tested
The weekly pace comes from pipelining the work, and none of the testing is dropped. Here is how Canonical lays out each cycle.
| Stage | What happens | Output |
|---|---|---|
| Continuous integration | Patches are integrated, the tree is snapshotted at the cutoff date, and initial CI sanity checks run | Candidate tree for the cycle |
| Week 1 – Prep | Kernel packages are built and smoke-tested to confirm they boot and run without obvious problems | Release candidates published to -proposed |
| Week 2 – Cert | Extensive certification, distro integration and regression testing | Completed test artifacts |
| Release | Kernel is released to users | Stable kernel update |
The Register describes the second week as the place for the heavier stuff, including hardware certification, distro integration, and regression testing. Once that's done, the kernel is released. Because the next cycle starts while that testing is under way, Canonical can publish another kernel the following week.
The hardware certification step is what makes the process slow, and it is also where most of the value sits. Canonical says it uses its Ubuntu Certified program to test the kernels across different hardware types. The company is also clear that it won't give this up to go faster: it will retain extensive testing for each release, and it acknowledges that expedited releases can't happen while every release candidate is tested thoroughly.
The rest of the SRU machinery stays in place. Ubuntu's documentation says patches destined for stable kernels are reviewed on the kernel team mailing list, and once a mailing list patch has been vetted and has at least two ACKs from senior members of the Ubuntu Kernel Team, the commit will then be applied to the associated stable Ubuntu kernel tree. The patch will then be considered for release in an upcoming SRU cycle if all the patch acceptance criteria are met. Respins, meaning rebuilds that replace an earlier kernel build to fix a regression or add an urgent patch, are also still supported. The same documentation keeps a caveat that applies under the new cadence too: SRU cycle dates are tentative. As such, they cannot be guaranteed and may be subject to change.
Where the CVE flood behind Ubuntu's decision comes from
Canonical gives two reasons for the change. The first is AI. The company says large language models (LLMs) and specialized AI agents have transformed bug discovery from a manual, time-intensive process into a highly automated engine.
The second is policy. The upstream kernel community became its own CVE Numbering Authority (CNA) and assigned CVE (Common Vulnerabilities and Exposures) identifiers to thousands of bugs, arguing that at the kernel level, almost any type of bug that can affect a running system, could potentially be classified as a vulnerability. The Register dates the kernel's CNA status to 2024. A CNA is an organization authorized to issue CVE identifiers for its own software, so since then the kernel maintainers have decided for themselves which fixes get an identifier, and they have been generous about it.
The two factors add up. Canonical says the result is a CVE volume that has skyrocketed exponentially, leaving defenders with a large backlog and forcing them to fix things much faster to shrink the window of risk. Canonical doesn't put a number on the backlog, and it doesn't say how much comes from AI-driven discovery versus the kernel's broader CVE assignment. Treat the AI explanation as Canonical's own account. What the schedule change clearly shows is that Canonical found the old 4/2 rhythm too slow for the flow of fixes it is now handling.
The -proposed pocket makes one-week Ubuntu kernel fixes a formal option
The biggest practical change for some shops is a faster path that Canonical now officially supports. Canonical's blog says users who are extremely sensitive to turnaround times can begin their own kernel acceptance tests using updates available in the -proposed pocket, which is where the kernel release candidates are published prior to starting certification testing and therefore updated weekly as part of the overlapping SRU cycles. This pathway is designed for users who have decided that faster remediation is a higher priority than waiting for Canonical's extensive certification testing.
In Ubuntu's archive, a pocket is a separate channel of packages for a release. -proposed is where packages sit for testing before they are promoted to general users. Ubuntu's documentation describes kernels ready for full testing being moved into a "testing" phase, with their binaries copied to a proposed location. Because the Ubuntu archive has only one proposed pocket, Canonical runs several kernel "streams" in parallel. That parallel setup made the old 4/2 model possible, and it is presumably what allows two cycles to overlap now.
The trade-off is simple to state. A kernel in -proposed after week one has passed builds and smoke tests, meaning it boots and runs with no obvious problems. It has not had the second week of hardware certification and regression testing. Help Net Security describes this as a sanctioned way to get a kernel CVE fix within a week by pulling release candidates from -proposed before Canonical has certified them. OMG! Ubuntu says enabling -proposed early is itself not without risk.
Canonical links to its own instructions for enabling -proposed, but the steps aren't covered here. Anyone who wants the early channel should follow Canonical's documented method and not improvise. Turning on a pre-release pocket carelessly can pull in more than kernel packages. That last point is general Ubuntu knowledge, and Canonical's announcement doesn't address it.
Ubuntu's 24-to-48-hour mitigation target covers the time before a patch
The third part of the plan is about the period before any kernel is ready. While a patch is being prepared, Canonical aims to provide safe workarounds where applicable, so users aren't left exposed in the meantime. Where no safe workaround exists, Canonical will say so clearly and point users toward general hardening steps instead. The goal is to get environments into a defensible, safer state within 24 to 48 hours of public disclosure – well before a patch ships.
This is a goal, not a guaranteed response time for every vulnerability, and Canonical says the mitigations don't replace the fix itself: the aim is to buy time to fix the vulnerability properly. Canonical's promise to say plainly when no safe workaround exists may be as useful as the workarounds. It tells an admin whether to wait, harden, or take a system out of exposure.
Put together, Ubuntu admins now have three tiers of response for a kernel CVE. A workaround or hardening advice should arrive within a day or two of disclosure where one exists. An uncertified release candidate in -proposed should follow roughly a week into a cycle. A fully certified kernel comes at the end of the two-week cycle. Each tier gives more assurance and arrives later.
What weekly Ubuntu kernels mean for your fleet
Help Net Security puts the main decision this way: anyone running an Ubuntu fleet should plan for weekly kernel releases and decide which machines, if any, can take uncertified builds. Most organizations can simply follow the certified releases on a faster rhythm. The -proposed route makes sense only where a team can realistically run its own acceptance tests and the risk of a kernel CVE outweighs the risk of a regression.
A weekly kernel also affects things beyond the patch tool. Kernel updates usually mean reboots or a live-patching arrangement. Maintenance windows, change-approval workflows, and any compliance reporting that tracks kernel versions were probably built around the 4/2 rhythm. The announcement doesn't cover how live patching fits the new cadence, so teams that rely on it should confirm with Canonical before they redesign their windows.
- Canonical's new overlapping two-week kernel SRU cycles replace the 4/2 cadence used since August 2023, and they begin with back-to-back cycles starting September 28 and October 12, 2026.
- Certified kernels will still get a full week of hardware certification, distro integration and regression testing before release, so the faster cadence is not a cut in testing.
- Kernels in
-proposedare available about a week into each cycle but have only passed builds and smoke tests, so use them only on systems where your team can run its own acceptance testing. - Canonical aims to publish safe workarounds or general hardening advice within 24 to 48 hours of a kernel CVE's disclosure, and will state explicitly when no safe workaround exists.
- Reboot schedules, maintenance windows and change-control processes built around a four-week kernel rhythm should be reviewed before weekly releases start in late October.
- Cycle dates remain tentative under Ubuntu's SRU policy, so check whether a specific CVE fix has shipped instead of assuming a fixed weekly delivery day.
Canonical is betting that running two release trains a week apart will keep up with the growing number of CVEs without giving up the certification testing its enterprise customers pay for. The first overlapping cycles begin once the back-to-back transition cycles end in late October. From then on, Ubuntu admins will see a new kernel every week and will need to decide, machine by machine, whether to wait for the certified build or test the week-one candidate themselves.