Canonicalは、通常のStable Release Updates(SRU)の4週間サイクルとセキュリティ修正の2週間サイクルを統合し、新たに2週間サイクル1本に一本化する新しいリリーススケジュールのもと、Ubuntuカーネルを毎週リリースするようになります。この2つのサイクルは互いに1週間ずつずれて重なり合う形で走るため、結果として毎週リリースが発生する仕組みです。
フルサイクルを待つよりも早くカーネルのCVE修正を必要とする管理者には、1週間以内に入手できる公式な手段が用意されました。Canonicalが認証テストを実施する前の段階で、-proposedポケットからリリース候補を取得する方法です。Ubuntu環境を運用する担当者は、今後は毎週カーネルがリリースされることを前提に計画を立て、未認証ビルドを適用してよいマシンがあるかどうかを判断する必要があります。
Canonicalは、安全な回避策が存在する場合、脆弱性の公表から24時間から48時間以内にその回避策を公開することを目標に掲げています。回避策が存在しない場合には、一般的な堅牢化対策を案内するとしています。
2つのスケジュールが1つに統合
修正はカットオフ日まで継続的に蓄積され、その時点でカーネルツリーのスナップショットが作成されます。最初の週にCanonicalはカーネルをビルドし、起動と動作を確認するスモークテストを実施します。そのビルドは、リリース候補を保持するUbuntuアーカイブの区画である-proposedに反映されます。続く2週目には、Ubuntu Certifiedプログラムの対象ハードウェア上で認証・統合・回帰テストが行われ、その週の終わりにカーネルがリリースされます。
Canonicalはこの変更を、既知の脆弱性に割り当てられる公開識別子であるCVEの件数と結びつけています。LLMやAIエージェントはバグハンティングの多くを自動化してきました。またLinuxカーネルの上流コミュニティ自体も独自のCVE Numbering Authorityとなり、動作中のシステムに影響を及ぼしうるカーネルバグはほぼすべて脆弱性になり得るとの考えから、数千件のバグに識別子を割り当てています。
高速レーンは未検証
Canonicalは、すべてのリリースに対して全面的なテストを維持する方針です。「すべてのリリース候補を徹底的にテストしながら、リリースを迅速化することはできません」と同社は述べています。
待てないチームは、毎週更新される-proposedビルドに対して独自の受け入れテストを開始できます。Canonicalはこれを、1週間以内にカーネルのCVE修正を得るための手段として位置づけており、より早く修正を入手するために認証段階を省略する意思のあるチーム向けだとしています。Canonicalが提供する最速のカーネルは、テストが完了していないカーネルにほかならず、そこに含まれる不具合はすべて、それを採用したチーム自身の問題となります。
翻訳元: https://www.helpnetsecurity.com/2026/09/24/ubuntu-kernel-cve-fixes-release-schedule/
