Linuxカーネルの公式CVEアーカイブに、2026年7月19日から20日にかけて440件の告知が集中した。公開時刻をたどると、最初の告知から最後までの幅は31時間18分で、7月19日だけで431件に達する。しかし、これは440件の脆弱性が一昼夜で見つかり、同じ時間内に修正されたという記録ではない。Linuxカーネルでは修正が安定版ツリーに入った後にCVEを割り当てるため、今回の数字は過去の修正をまとめて告知したバッチの規模を表している。
AIの寄与も、440件という総数からは測れない。告知本文でAI関与を確認できるのは少なくとも24件であり、ほかに一般的な静的解析ツールを挙げるものが3件あった。24件にはSashikoを明記した23件と、AI支援監査を発見経路とするXFSの1件が含まれる。AIが全自動でカーネルを直したという事実は、これらの告知には記されていない。
440件の内訳は「修正」ではなくCVE告知
公式アーカイブの時刻は、7月19日9時10分42秒（UTC）から20日16時28分51秒まで広がっている。したがって「24時間で400件超を修正」という捉え方は、時間幅と作業内容の双方を取り違える。数えられたのは、すでに修正commitが存在する問題へ割り当てたCVEの告知メールだ。
LinuxカーネルCVEチームは、通常の安定版リリース工程で潜在的なセキュリティ問題になり得る修正を探し、CVEを自動的に割り当てる。未修正の問題には自動付与しない。カーネルはシステムの根幹で動き、修正時点では悪用可能性が分からないバグも多いため、チームは慎重側に倒して広く番号を付ける方針を明記している。告知が多いこと自体は、同数の緊急事態や遠隔攻撃経路が生じた証拠にならない。
今回の440件は対象領域も広い。「Affected files」欄のパスを告知単位で数えると、driversを含むものが199件、netが114件、fsが66件あった。複数のディレクトリにまたがる告知があるため重複を含むが、ネットワークやファイルシステムに限った一つの事故ではなく、巨大なコードベースを横断して蓄積した修正だと分かる。
7.1系402件にまたがる「修正版」
各告知の「Affected and fixed versions」欄は、問題を導入した版と修正を取り込んだ版をブランチごとに示す。440件のうち、修正版として7.1系を記す告知は402件、6.18系は352件、7.0系は350件、6.12系は269件だった。一つの告知が複数ブランチを含むため合計は440を超える。
| 修正版として記載された系列 | 告知数 |
|---|---|
| 7.1系 | 402件 |
| 6.18系 | 352件 |
| 7.0系 | 350件 |
| 6.12系 | 269件 |
この分布から、一つの新しいパッチ版が440件を一挙に直したわけではないことが読み取れる。実際、告知の多くは7.1、7.0.11、6.18.34、6.12.93などを修正版として挙げており、修正は複数の時期と系列へすでに入っていた。CVEの公開が後からまとまったのである。
7月21日時点で、kernel.orgが示す最新安定版は7.1.4、メインラインは7.2-rc4だ。長期サポート版では6.18.39と6.12.96などが維持されている。7.1.4、6.18.39、6.12.96は7月18日に、7.2-rc4は19日に公開された。ただし、Debianは安定版パッケージへセキュリティ修正をバックポートし、安全な版かどうかをDebian Security Advisory記載の正確なパッケージ版と照合するよう案内している。上流の版番号だけで、Debian環境の修正状況は決められない。
AI関与を追えるのは少なくとも24件
440件の告知本文を確認すると、Linuxカーネル向けAIコードレビューシステム「Sashiko」を明記したものは23件だった。これとは別に、CVE-2026-64187がAI支援のコード監査を発見経路として記している。告知から直接たどれるAI関与は、少なくとも24件となる。
SashikoはLinux Foundationに属するオープンソースのレビューシステムで、公開メーリングリストへ投稿されたパッチを監視する。複数段階のプロトコルでアーキテクチャとセキュリティを点検し、リソース管理や並行処理も調べる。公開サービスの計算資源とLLMトークンはGoogleが提供している。
CVE-2026-64187は、その境界がよく見える例だ。XFSのリカバリ処理が、領域を持たないコミット済みログ項目を読むとNULLポインタ参照に至る。通常動作では生成されず、細工したログで起きる経路をAI支援監査が見つけた後、修正は6.12.96、6.18.39、7.1.4、7.2-rc4へ取り込まれた。
一方、Bluetooth L2CAPのデッドロックを直したCVE-2026-64206は、静的解析ツールで発見し、現行ツリーに対して人手でレビューしたと説明する。静的解析という語だけでLLM利用までは判断できない。今回、この表現を使った告知は3件あった。CVE-2026-64206については、ツールによる発見と人手による採否判断が分かれていたことを確認できる。
Sashikoが関わったCVE-2026-64115では、vsock/VMCIの接続確立中に接続相手がリセットを返すと、解放済みソケットへ再度書き込む経路が問題になった。告知に記されたKASAN試験では、未修正版で100回中52回再現し、修正版では100回中0回だった。この事例では、Sashikoの指摘を再現試験で確かめたうえで修正している。
総数より先に、稼働構成と配布元の更新
LinuxカーネルCVEチーム自身が、大量のCVEの多くは個々のシステムに該当しない場合があると説明している。ソースツリーは巨大で、実際に使われるのは構成、ロードしたモジュール、接続したハードウェア、外部へ公開したインターフェースに応じた一部だからだ。440という数字だけで、すべてのLinux機が同じ危険にさらされたとは判断できない。
管理者はまず稼働中のカーネルパッケージを確認し、利用するディストリビューションや機器ベンダーのセキュリティ勧告と照合する必要がある。その上でBluetoothと仮想化の利用状況を調べる。ファイルシステムやネットワークドライバも、実際に有効な領域から優先する。独自ビルドのカーネルでは、対応する上流コミットが取り込まれているかを確認しなければならない。
公式方針は、個別コミットを選んで適用するより、まとめてテストされた安定版の更新を受け取ることを勧めている。管理者は、配布元の勧告が示す修正版を確認する必要がある。440件のバッチで管理対象は増えた。実際の更新優先度は、各環境でそのコードが有効か、配布元が修正を取り込んだかで決まる。
