AIによるバグ発見が相次ぐLinux、ついに修正が追いつき始めた？ BPF開発で見えた転機

Linus Torvalds氏は日本時間11月9日、Linux 7.4の第2リリース候補版「7.4-rc2」を公開し、BPFではバグ修正が新たな発見を上回りつつあるという担当者の見方を紹介した。AIを使ったバグ探索が続くなかでの前向きな報告だが、Torvalds氏自身は改善を断定していない。BPFはLinuxカーネル内でプログラムを実行する仕組みで、実行前に危険なメモリーアクセスなどを調べる検証器を備えている。ただし、新たに見つかるバグが減ることと、修正が新規報告に追いつくことは別の話だ。11月3日の取り込み記録と検証器の具体的な修正をたどると、改善の実態と、なお残る課題が見えてくる。

BPFで修正が新規報告を上回る兆し、ただし改善は限定的

BPF担当のAlexei Starovoitov氏は、11月3日に取り込まれた修正の説明で、バグを修正するペースが新たな発見を上回っているようだと述べていた。Torvalds氏が7.4-rc2の告知で取り上げたのは、この担当者の評価である。もっとも、BPFの取り込み記録には、まだ危機を脱したわけではなく、sockmapの修正は後日になるとも記されている。Torvalds氏も、改善が事実なら喜ばしいと評価する一方、ほかの多くの領域はまだ同じ状況に達していないと述べた。7.4-rc2のリリース告知では、引き続き試験を行うよう呼びかけており、Linux全体でバグ修正が新規発見を上回るようになったと宣言したわけではない。

修正が新規報告を上回る状態は、新たに見つかるバグが減った場合にも、修正作業が速くなった場合にも起こり得る。両方が同時に進んでいる可能性もある。しかし、今回の告知や取り込み記録には、一定期間における新規報告数、修正数、未修正の残件数といった統計は示されていない。レビューに費やした時間も不明であり、AIによる探索で発見可能な欠陥が減ってきたのか、保守担当者の負担が軽くなったのかは判断できない。現時点で確認できるのは、BPF担当者が修正の進捗を前向きに評価し始めたという変化だ。

Linux 7.4-rc2の変更量をAIによる修正件数と混同してはいけない

Linux 7.4-rc2の変更量が大きくなった背景には、最初のリリース候補版（rc1）から持ち越されたCoccinelleによる自動変更もある。Coccinelleはソースコードから特定のパターンを検出し、まとめて書き換えるためのツールだ。Torvalds氏は、出張中にこれらの変更を扱うのを避けるため、rc1への取り込みを見送り、rc2に回したと説明している。変更の大半は1〜2行程度の単純な書き換えだが、数千ものファイルに分散しているため、変更量の集計では大きな割合を占めている。

Torvalds氏によると、Coccinelleの自動変更を除いた変更量は、約3分の1がドライバー関連、約3分の1がネットワークとBPF関連で、残りがファイルシステム、メモリー管理、各CPUアーキテクチャー向けの変更などとなっている。これは開発領域ごとのおおまかな変更量を示したものであり、AIが発見したバグの件数ではない。リリース告知でも、Coccinelleによる機械的な書き換えと、AIを使ったバグ発見に関連する修正は区別して説明されている。

そもそも、変更されたファイル数やコミット数は、そのままバグの件数を意味するわけではない。1件のバグを修正するために複数のコミットが必要になることもあれば、修正を検証するためのテストが別のコミットとして追加されることもある。BPFで実際に何が進展しているのかを理解するには、変更量だけでなく、修正された処理の内容と、その正しさを確かめるためのテストを確認する必要がある。

BPFの61コミットから見える修正と検証の実態

11月3日に取り込まれたBPFの61コミットには、バグを修正するコードだけでなく、修正が正しく機能することを確かめ、再発を防ぐためのテストも含まれている。つまり、61件の脆弱性が見つかったという意味ではない。取り込み記録にある「61 commits」という表記とコミットの件名一覧からは、少なくとも次の2種類の作業を確認できる。

コミットの区分	主な作業	数字を読む際の注意
bpf:の修正本体	検証器などの誤った処理を修正する	コミット数はバグの件数やAIが生成した修正件数とは一致しない
selftests/bpf:のテスト	修正対象の動作を検証し、バグの再発を防ぐ	テストの追加も61コミットに含まれている

取り込み記録のコミット件名一覧は末尾が省略されているため、61コミットすべての正確な内訳や割合を算出することはできない。それでも、バグ修正には誤った処理を書き換えるだけでなく、修正後の動作を検証する作業が伴うことが分かる。特にBPFでは、危険なプログラムを実行させないことと、安全なプログラムを誤って拒否しないことの両方が重要になる。

BPFの検証器は、プログラムの命令から危険な処理を探すだけの仕組みではない。レジスターに格納された値の型や取り得る範囲、スタック上のどの領域に書き込みが行われたかなどを追跡し、範囲外のメモリーアクセスや未初期化データの読み出しを防ぐ。Linuxカーネルの公式文書で説明されているこうした解析が、プログラムを安全に実行できるかどうかを判定する基盤となっている。

この追跡処理に不整合が生じていた例が、11月2日の修正コミットcdefba74だ。問題は、関数の呼び出し先が、呼び出し元のスタックに保存されたポインターを書き換えられることに関係していた。実行時にはポインターが別のメモリー領域を指すように変更されても、解析側がその変化を正しく把握せず、以前の参照先を前提に処理を続ける場合があった。実際のプログラムの状態と、検証に使う内部情報が食い違っていたのである。

修正コミットの説明によると、この不整合は2種類の問題を引き起こす可能性があった。一つは、実際に行われる書き込みを解析側が見逃し、BPF mapの領域外へのアクセスを許してしまう問題だ。もう一つは、本来なら安全に実行できるプログラムを誤って拒否してしまう問題である。後者では、解析側がまだ必要なスタック上の値を不要と判断し、後続の読み出しを不正と判定する場合があった。同じポインター追跡の不整合が、危険なプログラムの受け入れと、正常なプログラムの拒否という逆方向の誤判定につながっていた。

今回の修正では、呼び出し先が呼び出し元のスタック上にあるポインターを書き換えられる場合、解析側がそのポインターの参照先を確定したものとして扱わないようにした。書き換えの可能性を考慮し、確実には分からない情報を前提とした判断を避ける仕組みだ。これによって安全性を高められる一方、解析の精度が変わるため、従来は正常に受け入れられていたプログラムへの影響も確認する必要がある。修正コードが比較的小規模でも、その影響まで小さいとは限らない。

修正の作者は、Linuxカーネルのselftestsに加え、Ciliumとsched_extを含む計12,522プログラムを使って影響を調べたと報告している。その結果、スタックの追跡情報が変化したのは4プログラムだけで、プログラムの受け入れ・拒否の判定結果や、解析した命令数、解析中の状態数には変化がなかったという。これは、報告された試験範囲では既存プログラムへの影響が限定的だったことを意味する。ただし、未知のプログラムを含むすべての環境で互換性や性能が保証されたわけではない。安全性を高める修正を加えたうえで、既存プログラムの判定に悪影響がないかを具体的な数字で確認している点が重要だ。

なお、このポインター追跡の問題について、AIが発見した、あるいはAIが修正コードを生成したという明記は確認できない。AIを使ったバグ探索が活発化するなかで実施されたBPF修正の具体例ではあるものの、AIの発見能力を示す実績として数えることはできない。

AIが発見したバグを「検証済みの修正」にするために

Linuxカーネルでは、AIを利用してバグを発見・修正する際の手順も整備されている。公式文書の「AI Coding Assistants」は、AIが指摘した問題をそのまま報告するのではなく、実際に発生するバグかどうかを確認するよう求めている。軽微な例外を除いて修正案の作成を必須とし、修正が正しく機能することをビルドや再現用コード、再解析によって確かめることも求める。AIが疑わしいコードを見つけるだけでは不十分であり、実際に適用可能な修正として提出するまでの作業を重視した手順だ。

具体的には、まず問題が存在するバージョンやコミットを特定し、実際にバグが起こることを可能な限り再現する。そのうえで修正コードを作成し、元の問題を引き起こした条件で再び検証する。修正はビルド時に新たな警告を発生させず、コードの書式などを確認するcheckpatch.plの検査にも合格しなければならない。さらに、問題を導入したコミットを示すFixesタグを付け、修正を送るべき担当者やメーリングリストを特定することも求められる。

重要なのは、実施していない検証を済ませたかのように報告してはならないという点だ。再現用コードを作成できなかった場合や、ビルドや試験を実施できなかった場合には、その事実を明示する必要がある。確認済みの事実とAIが推測した影響を明確に区別すれば、保守担当者は残された検証作業を把握できる。反対に、どこまで確認されているのか分からない報告では、問題が実在するかどうかの調査から担当者がやり直さなければならない。

セキュリティ上の問題を扱う「Security bugs」ガイドでは、AIを使ったバグ報告に伴う負担がさらに具体的に説明されている。AIが生成した報告は、不必要に長い文章や過剰な装飾が含まれやすく、重要な情報を見つけにくくするという。また、実際に確認していない影響を推測だけで誇張する報告も、問題の評価を難しくする。再現できないバグの報告が増えれば、保守担当者は存在が確認できていない問題の調査に時間を費やすことになる。そのため、報告には影響を受けるバージョンやコミット、問題の具体的な説明、再現用コード、発生条件などを明確に記載するよう求めている。

同ガイドは、AIを使った複数の研究者が同じバグをほぼ同時に発見するケースにも言及している。このため、AIを利用して発見した問題は原則として公開情報として扱う一方、悪用を防ぐため、再現用コードは公開せず、担当者から求められた場合に非公開で共有するよう指示している。ただし、セキュリティ上の脆弱性に該当するか判断が難しい場合には、非公開で報告することも認めている。AIで発見した問題をすべて無条件に公開するという方針ではなく、報告内容とリスクに応じた対応が求められる。

提出するコードに対する責任も、最終的には人間が負う。「AI Coding Assistants」では、開発者がコードの出所とライセンス上の責任を保証するSigned-off-byタグを、AIエージェント自身が追加することを禁じている。人間の開発者がAI生成コードをレビューし、ライセンス要件を確認したうえで、貢献全体に責任を持つ必要がある。AIがバグを発見して修正案を生成できても、それだけでLinuxカーネルに取り込めるわけではない。

今回のBPFにおける修正ペースの改善が、こうした開発手順によってもたらされたと示す測定結果はない。それでも、AIによるバグ探索が広がるなかで、発見件数だけでなく、再現性の確認から修正、テストまでを一貫して行うことの重要性は増している。Torvalds氏が7.4-rc2の告知で試験の継続を求めたのも、修正が進んでいるという報告だけでは十分ではないためだ。今後は、BPFで修正が新規報告を上回る状態が続くのか、未修正の問題が実際に減っていくのかが、改善を判断する重要な指標となる。