Canonical is changing the way Ubuntu kernel security updates are prepared and released as the volume of vulnerabilities identified through automated security analysis continues to grow. The company will move to a two-week kernel update cycle, while overlapping development cycles will allow a new kernel update to be published each week. Canonical will also provide faster mitigation options for critical vulnerabilities when possible.

The key facts about Ubuntu kernel updates in 20 seconds

Canonical is moving kernel update cycles to two weeks.
Overlapping cycles will allow Ubuntu to publish a new kernel update every week.
The first week focuses on preparation, integration and initial testing.
The second week covers certification, integration and regression testing.
The -proposed repository provides an earlier testing path, while critical issues may receive mitigations within 24 to 48 hours when possible.

The change comes as the Linux kernel faces a growing number of vulnerabilities that need to be identified, classified, fixed and distributed. Canonical says large language models (LLMs) and AI agents are making vulnerability discovery faster, increasing the volume of security issues that developers and maintainers need to process.

Canonical also points to changes in the Linux kernel vulnerability process. Since 2024, kernel maintainers have increasingly handled vulnerability identification and assignment as a CVE Numbering Authority (CNA), meaning that more issues that might previously have been treated simply as software bugs can receive Common Vulnerabilities and Exposures (CVE) identifiers.

For Canonical, that creates a practical challenge: more vulnerabilities require analysis and fixes, but security updates still need to go through testing before reaching Ubuntu users.

Ubuntu will publish a new kernel update every week

The new system does not mean that every individual kernel update will be developed and released without the previous testing process. Instead, Canonical is shortening the individual release cycle to two weeks and overlapping several cycles.

During the first week, Canonical prepares the kernel update. This includes selecting patches, integrating fixes, building the packages and carrying out initial checks. Once this stage is complete, the candidate is made available through the -proposed repository. (canonical.com)

The second week focuses on certification, integration and regression testing. Canonical uses its certification process to test Ubuntu kernels across different hardware configurations before making them generally available. (canonical.com)

The important detail is that these cycles run in parallel. While one kernel is undergoing certification and testing, the next kernel update is already entering its preparation phase.

As a result, Ubuntu will be able to publish a new kernel update every week, even though each individual update still goes through a two-week process.

That distinction matters for administrators. The change is not simply about cutting testing time in half. Instead, Canonical is changing the scheduling of its kernel maintenance process so that security fixes can move through the pipeline more frequently without removing the validation stages.

For data centers, cloud servers and other environments running Ubuntu at scale, the new model should reduce the time between the preparation of security fixes and their general availability.

Canonical keeps a faster path for urgent vulnerabilities

A two-week cycle can still be too slow for organizations dealing with an actively exploited or particularly serious vulnerability. Canonical therefore continues to provide the -proposed repository as an earlier route for organizations that need to begin testing a kernel before its full certification process has finished.

Administrators can use these candidate versions to perform their own acceptance testing. The trade-off is that the organization assumes more responsibility for validating the kernel instead of waiting for Canonical’s complete certification process. (canonical.com)

Canonical also describes a separate approach for situations where a complete patch cannot be prepared immediately. When possible, the company says it will provide temporary security mitigations within 24 to 48 hours for critical vulnerabilities.

These mitigations are not intended to replace the final fix. Their purpose is to reduce exposure while developers prepare, test and distribute the permanent correction. If a safe mitigation is not available, Canonical says it will communicate that and recommend broader security-hardening measures where appropriate. (canonical.com)

This creates several response options depending on the situation. Organizations can wait for a fully tested kernel, begin testing an earlier candidate through -proposed, or apply a temporary mitigation when Canonical has one available.

AI is accelerating vulnerability discovery

The role of artificial intelligence is one of the most notable aspects of Canonical’s announcement. The company says LLMs and specialized AI agents are increasingly capable of automating vulnerability discovery and code analysis.

That can help security researchers find problems that might otherwise take longer to identify. It also creates additional pressure on the teams responsible for maintaining operating systems because vulnerabilities can enter the remediation pipeline faster than before. (canonical.com)

Canonical has also been developing its own AI-based security tools. The company says its Redhound tool has already identified three critical logic vulnerabilities in the Linux kernel, illustrating how AI-assisted analysis can uncover problems that are not necessarily detected by traditional testing alone. (canonical.com)

The broader challenge is therefore not simply finding vulnerabilities. Once a vulnerability is discovered, maintainers need to understand its impact, develop a fix, test it against different configurations and hardware, certify the result and distribute it without introducing new regressions.

Canonical’s new schedule is designed around that entire process.

For desktop Ubuntu users, the change could mean seeing kernel updates more frequently rather than waiting for larger monthly releases. For enterprise administrators, the effect is potentially more relevant because shorter release intervals can reduce the time systems remain exposed after a vulnerability has been identified.

At the same time, more frequent updates also mean more work for organizations that operate large Ubuntu deployments. Administrators need to test updates, schedule maintenance and monitor applications and workloads for compatibility.

The change therefore reflects a broader shift in software security driven partly by AI. As automated systems become better at finding vulnerabilities, operating-system maintainers need faster ways to process them without sacrificing the testing required before deploying kernel changes across production systems.

Canonical’s solution combines two-week development cycles, overlapping releases, weekly kernel publications and rapid mitigations when possible. The company is keeping certification and regression testing in the process while providing earlier access to candidates for organizations that need to move faster.

Frequently asked questions

How often will Ubuntu publish kernel updates?

Canonical is moving individual kernel cycles to two weeks. Because multiple cycles will overlap, a new kernel update can be published every week.

What is Ubuntu’s `-proposed` repository?

It contains candidate packages that are available before the full certification process is completed. Organizations can use them to begin testing security fixes earlier.

Will Canonical fix critical vulnerabilities within 24 hours?

Not necessarily. Canonical says it will provide temporary mitigations within 24 to 48 hours when a safe mitigation is possible. These measures are temporary and do not replace the final kernel fix.

Why is AI increasing pressure on Linux kernel security teams?

According to Canonical, LLMs and specialized AI agents can automate parts of vulnerability discovery and accelerate code analysis. That can increase the number and speed of vulnerabilities entering the remediation process.