Ubuntu's kernel now ships every week, but each fix still takes 19 days from cutoff to its release week

The same cutoff, two release weeks

On 4 September, the Ubuntu kernel team posted the schedule for its SRU cycle starting 28 September. Kernel patches had to be in by Wednesday 23 September, and the cycle ran four weeks, with release to -updates in the week of 26 October. That is 33 days from cutoff to the start of the release week.

The schedule on kernel.ubuntu.com, read today, shows the same cycle with the same 23 September cutoff, now marked 2 weeks, with prep and testing from 28 September to 9 October and release in the week of 12 October. That is 19 days. Fixes that made that cutoff are scheduled to reach -updates two weeks sooner than they were three weeks ago.

This is the first cycle under the cadence Canonical announced on 23 September in a post titled "Accelerating delivery of CVE fixes with a new Kernel release strategy". The old model ran a 4-week regular cycle and a 2-week security cycle. The new one is a single 2-week cycle, started every week, so that a kernel is released every week.

What that does not establish. Both dates are schedules, and kernel.ubuntu.com says that "all dates are tentative and are subject to change". Nothing here measures a real fix. And 19 days is not new for urgent security fixes: the old two-week security cycle already ran on the same 19 days from cutoff to release week, as the July and August 2026 schedule shows. The gain is large for regular fixes and one week, at most, for the critical and high CVE fixes that already had a fast lane.

What Canonical changed

Since August 2023 the Ubuntu kernel has run what the team calls a 4/2 cycle. The 2023 announcement describes a 4-week stable update carrying upstream stable updates, security and bug fixes, plus a mid-cycle update that contained "only CVE fixes rated critical or high" and other urgent fixes. Cutoffs for the generic kernels fell on the last Wednesday before a cycle started.

The new model, in Canonical's words, is "a unified, rapid 2-week SRU cycle, published weekly". Week one is preparation: builds and smoke tests, ending with the kernel published in the -proposed pocket. Week two is certification, distribution integration and regression testing on certified hardware. Then the kernel is released. Because a cycle begins every week, the two weeks overlap and a kernel leaves every week.

The post adds two things. Users who want fixes faster can start their own acceptance testing from -proposed, where release candidates appear weekly, before Canonical's certification is done. And while a patch is being prepared, Canonical aims to publish a workaround, or say plainly that none exists and point to hardening, within 24 to 48 hours of public disclosure. There is a precedent: for Copy Fail, CVE-2026-31431, in May, the kernel team expedited a security cycle and the security team shipped a kmod mitigation disabling the affected module in the interim.

Weekly is how often a kernel leaves, not how old a fix is

"Weekly kernel" is a comforting label. It describes the release interval. It says nothing about how long a given fix spends in the pipeline, and that is still two weeks of prep and certification plus the wait for the next cutoff. No fix is a week old when it ships.

The table below models the wait from the moment a fix is merged to the Monday of its release week. It is our derivation, from the published dates and the Wednesday cutoff described in 2023. The best case is a fix merged on cutoff day. The worst case is one merged the day after, which waits for the next cutoff. We assume each weekly cycle keeps a Wednesday cutoff; the schedule shows only the first one.

Days from a fix being merged to the start of its release week, old and new models. Our derivation from kernel.ubuntu.com and Ubuntu Discourse schedules; the release day within the week is not stated

Path	Old model	New model
Critical or high CVE fix, best case	19 days	19 days
Critical or high CVE fix, worst case	32 days	25 days
Regular fix, best case	33 days	19 days, if included
Regular fix, worst case	60 days	25 days, if included
New kernel in -proposed, to end of prep week	Not modelled	9 to 15 days

Two readings follow. For the urgent fixes, the worst case falls by a week, from 32 days to 25, and the best case does not move. For everything else, the change is large, up to five weeks sooner, but only if every class of fix rides every weekly cycle. Canonical's own description says the prep week is where "we select what updates and patches land on each kernel depending on specific needs", which leaves that open.

The -proposed route is the only one that gets under three weeks, and it is a route in which you do the certification. Ubuntu's archive documentation describes -proposed as a staging environment users opt into "to verify the stability of any updates". Canonical frames it as a choice for users who put faster remediation above its testing. That is honest, and it is also a transfer of work.

Released is not running

There is a second comfortable word in the story: released. A kernel in -updates protects nothing until the machine boots into it. A weekly kernel release only helps an estate that reboots on something close to a weekly rhythm, and most production estates do not.

Canonical's answer to the reboot problem is Livepatch, which its product page says patches critical and high severity kernel vulnerabilities while the system runs, as part of the paid Ubuntu Pro subscription. The 23 September post does not mention Livepatch, Ubuntu Pro, LTS or ESM at all. So it does not say whether livepatches will now arrive on the weekly rhythm, whether they change, or whether anything differs for Pro customers. Canonical sells Pro, and a faster free kernel cadence is also an argument for the paid way to apply it without a reboot. That is a commercial interest worth noting, not a reason to doubt the schedule.

The volume argument, and what it leaves out

Canonical's case for the change is volume. It says AI-driven bug discovery and the kernel's own CVE Numbering Authority, which assigns identifiers to "thousands of bugs", have made CVE volume skyrocket. The post carries a chart of monthly kernel CVEs from a third-party tracker but states no number in its text.

We counted from NVD, taking records whose source is the kernel CNA and excluding rejected ones: 4,287 published in 2024, 5,676 in 2025 and 7,155 from 1 January to 27 September 2026. This year has already passed all of last year, and September to the 27th alone brought 2,114. At this year's average that is about 186 new kernel CVE records a week. Not all of them affect a given Ubuntu kernel, and NVD records the publication date, not when a fix landed.

That is the same pressure behind today's other change. CISA ended its weekly Vulnerability Bulletin this morning, after a final edition whose largest section had no severity at all (our briefing). CISA answered volume by dropping severity sorting and pointing at exploitation. Canonical answers it with cadence. Neither tells you which fixes matter to you.

What the 23 September Canonical post states and does not state, checked against the post in full

Question	Stated	Not stated
Cycle length and release interval	Two-week cycle, weekly release	Cutoff day for later cycles
Start date	No	First 2-week cycle is on kernel.ubuntu.com: 28 September
CVE counts	A chart, no figures	Any number, or any backlog size
Which fixes ride each weekly cycle	Selected per kernel by need	Whether medium and low CVE fixes ride every cycle
Effect on exposure	Aim to close the window of risk	Any measure that exploitation windows shrink
Ubuntu Pro, LTS, ESM, Livepatch	Nothing	Any change for these customers
Workarounds	Aim: 24 to 48 hours after disclosure	How the target will be measured or reported

One small inconsistency: the kernel team's own documentation page on stable release updates still describes the 4/2 cadence today. Anyone who wrote internal patch policy from that page should expect it to change.

What to do

The question that matters

Canonical has made kernels leave faster. Whether any server is safer depends on the part of the journey Canonical does not control: the reboot. So the question for any Ubuntu estate is not how often a kernel is released but this: how many days pass between a fix reaching -updates and your machines running it, and has anyone measured it?

Key facts