操作系统平台

CVE洪水迫使Ubuntu转向每周内核发布周期

AI辅助的漏洞挖掘正在使漏洞的增长速度超过防御者的修补速度，因此Canonical正在加快发布节奏。

Canonical正将Ubuntu内核的发布频率提升至每周一次，以应对AI辅助漏洞挖掘带来的不断增长的CVE（通用漏洞披露）数量，这使防御者不堪重负。

Ubuntu的制造商正在彻底改革其内核稳定版更新（SRU）的发布方式，用重叠的双周周期取代当前的四周常规和两周安全周期，从而实现每周发布一次内核。

Canonical表示，这一改变是必要的，因为报告的漏洞数量激增，而AI对此负有部分功劳——或者说是罪责，这取决于你站在修补队列的哪一边。

Canonical在周三表示：“大型语言模型（LLM）和专用AI代理已将漏洞发现从一项手动、耗时的过程转变为高度自动化的引擎。”

AI并非CVE雪崩的唯一原因。上游Linux内核社区在2024年成为CVE编号机构，并开始基于“几乎任何影响运行中系统的内核缺陷都可能具有安全影响”这一前提，为数千个漏洞分配标识符。

将两者结合起来，Linux供应商需要处理的CVE数量大幅增加。Canonical表示，由此产生的积压需要通过更快的发布来缩短从漏洞公开到修补版内核到达用户手中的时间窗口。

在新系统下，每个SRU周期持续两周，但新周期每周启动一次。第一周用于集成补丁、准备和构建内核包，并执行基本检查以确保一切正常。在该阶段结束时，候选版本将发布到Ubuntu的-proposed存储库中。

第二周留给更繁重的工作，包括硬件认证、发行版集成和回归测试。一旦完成这些工作，内核即可发布。由于下一个周期在测试进行时启动，Canonical可以在下周发布另一个内核。

对于那些认为这仍然过于悠闲的管理员来说，还有更快的途径。

对修补延迟特别敏感的组织可以在第一周后从-proposed存储库获取候选版本，并运行自己的验收测试。Canonical明确说明了这种权衡：这些用户能更早获得修复，但此时公司尚未完成其广泛的认证测试。

只要客户愿意自行执行部分测试工作，内核CVE修复便可在一周内提供。

Canonical还希望减少客户在漏洞披露与修补可用之间的暴露时间。它旨在尽可能提供安全的工作区，或在没有工作区时建议一般的加固措施，使系统在公开披露后的24至48小时内进入其所谓的“可防御、更安全状态”。

这些措施并非旨在替代修补，而只是给管理员提供一种比在修复通过发布流程时干着急更好的选择。

最终结果是内核发布日程变得相当繁忙，尽管当机器被越来越多地用于以超过人类修补速度的速度寻找漏洞时，这也许是不可避免的。

人工智能本应让每个人的工作更轻松。Ubuntu的内核团队或许想对此说点什么。®

os platforms

CVE flood pushes Ubuntu onto weekly kernel release cycle

AI-assisted bug hunting is helping pile up vulnerabilities faster than defenders can patch them, so Canonical is picking up the pace

Canonical is speeding up Ubuntu kernel releases to one a week as AI-assisted bug hunting helps bury defenders under an ever-growing pile of CVEs.

The Ubuntu maker is overhauling how it ships kernel Stable Release Updates (SRUs), replacing its current four-week regular and two-week security cycles with overlapping two-week cycles that will push a kernel release every week.

Canonical says the change is needed because the number of reported vulnerabilities has exploded, with AI deserving some of the credit – or blame, depending on which side of the patch queue you're sitting.

"Large language models (LLMs) and specialized AI agents have transformed bug discovery from a manual, time-intensive process into a highly automated engine," Canonical said on Wednesday.

AI isn't solely responsible for the CVE avalanche. The upstream Linux kernel community became a CVE Numbering Authority in 2024 and began assigning identifiers to thousands of bugs on the basis that almost any kernel flaw affecting a running system could have security implications.

Put the two together, and Linux vendors have far more CVEs to deal with. Canonical says the resulting backlog requires faster releases to shrink the window between vulnerabilities becoming public and patched kernels reaching users.

Under the new system, each SRU cycle lasts two weeks, but a new one starts every week. The first week is spent integrating patches, preparing and building kernel packages, and carrying out basic checks to make sure nothing catches fire. By the end of that stage, release candidates are published to Ubuntu's -proposed pocket.

Week two is reserved 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.

For admins who consider even that too leisurely, there's a faster route.

Organizations particularly sensitive to patching delays can take release candidates from the -proposed pocket after the first week and run their own acceptance tests. Canonical makes the trade-off clear: those users get access to fixes sooner, but before the company has finished its extensive certification testing.

That can make kernel CVE fixes available within a week, provided customers are willing to perform some of the testing themselves.

Canonical also wants to leave customers less exposed between disclosure and patch availability. It aims to provide safe workarounds where possible, or recommend general hardening measures where none exist, putting systems into what it calls a "defensible, safer state" within 24 to 48 hours of public disclosure.

Those measures are not intended to replace patching, merely to give admins something better than crossing their fingers while a fix makes its way through the release process.

The end result is a considerably busier kernel release schedule, although perhaps that's inevitable when machines are increasingly being enlisted to find bugs faster than humans can patch them.

AI was supposed to make everyone's jobs easier. Ubuntu's kernel team may want a word. ®