Accelerating delivery of CVE fixes with a new Kernel release strategy

When it comes to fixing security vulnerabilities, speed is crucial. Canonical is officially outlining 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 brave new world

The recent explosion in the volume of CVEs is fueled by artificial intelligence: large language models (LLMs) and specialized AI agents have transformed bug discovery from a manual, time-intensive process into a highly automated engine. Additionally, 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. As a result, the volume of CVEs has skyrocketed exponentially, creating a massive backlog of alerts and forcing defenders to drastically increase the speed of their fixes to close the window of risk.

The path to a reliable unified 2-week kernel SRU

To address the growing volume of CVEs and the demand for faster security fixes, we are transitioning to a unified, 2-week release cycle.  These recurring 2 week cycles cascade: each cycle begins the week after the previous one starts. Because of this overlap, kernel releases will take place weekly. The first week will focus on Kernel packages preparation. This is where we select what updates and patches land on each kernel depending on specific needs. The second week on testing for Ubuntu certifications. Through our Ubuntu Certified program, we rigorously test these kernels on different hardware types to ensure the best Ubuntu experience.

The path to 1-week kernel CVE fixes availability

Expedited releases aren’t possible while thoroughly testing every release candidate. We will retain extensive testing for each release, preserving the high degree of confidence the users of Ubuntu expect. That said, it is important to acknowledge that some environments require the fastest possible turnaround.  

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. Learn here how to enable proposed.

Staying protected before the patch ships

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 doesn’t replace the patch; it buys the time needed to fix the vulnerability properly, without sacrificing security.

Anatomy of the new, 2-week Kernel SRU cycle

Here is how the new cycle breaks down:

• Continuous integration of fixes for the upcoming cycle: 

Patch integration, snapshot of the tree at the cutoff date, and initial CI sanity checks

• Week 1 – Prep (builds and smoke tests): 

A 1-week kernel preparation phase with builds and basic checks to confirm kernels boot and run with no obvious issues. By the end of this stage builds are published in -proposed

• Week 2 – Cert (extensive testing): 

Extensive certification, distro integration, and regression testing. By the end of this stage all test artifacts are completed

• Release: 

Kernels are released