TopicBase
Linuxの開発を率いるリーナス・トーバルズ氏は、Linuxカーネル7.4-rc2について、変更の多くがAIを活用した修正によって進んだと述べました。カーネル内の仕組みであるBPFでは、新たな不具合報告よりも修正が速いペースで届いているとの開発者の見方を紹介し、状況が変わり始めた可能性に言及しています。
BPFで修正のペースに変化、他の領域には慎重な見方
トーバルズ氏が紹介したのは、BPFの保守担当者であるアレクセイ・スタロヴォイトフ氏の見方です。BPFでは修正が新規報告を上回るペースで届いているとする一方、トーバルズ氏自身は、それが事実なら好ましいと条件を付けています。
トーバルズ氏は、他の多くの領域はまだ同じ段階に達していないとの認識も示しました。改善の兆しと受け止めながらも、今後の進展には慎重な期待を示し、開発者らにテストの継続を求めています。
7.4-rc2は、過去最大規模のrc1に続く大規模な更新です。ただし、変更量の統計では、コードの定型的な書き換えに使うツール「Coccinelle」による自動更新が目立っています。これらの多くは1〜2行の変更で、多数のファイルに分散しているため、見かけの規模が大きくなっています。
その自動更新を除くと、変更のおよそ3分の1はドライバーで、主に画像処理、ネットワーク、音声関係が占めます。別の約3分の1はネットワークとBPF、残りは主にファイルシステム、メモリー管理、各種アーキテクチャー対応です。
BPFの修正が関わるカーネルの安全性
BPFの拡張版であるeBPFは、カーネル本体のコードを変更せずに機能を拡張する仕組みです。ネットワークのパケット処理に加え、性能監視、システムの動作追跡、セキュリティーチェックなどにも使われ、利用者が定義したプログラムをカーネル内で実行できます。
eBPFには、プログラムの実行前に安全性を調べる「検証器」があります。メモリーへのアクセス範囲や、メモリー上の位置を指すポインターの使い方などを検査します。一方、検証器自体にも脆弱性が見つかっており、検査をすり抜けた処理は、権限昇格、データ破損、サービス妨害などにつながるおそれがあります。
また、eBPFプログラムがパケットデータへのアクセスなどに使う補助関数は、安全性の確認を検証器に依存しています。不適切なプログラムが検査を通過すると、補助関数を通じてカーネルのメモリーが読み書きされる危険があるため、BPF周辺の不具合修正はカーネルの安全性にも関わります。
AIで作った修正も人間が検証と責任を担う
Linuxカーネル開発では、AI支援を使う場合も通常の開発手順やコーディング規約に従う必要があります。人間の提出者には、AIが生成したコードをすべてレビューし、ライセンス要件への適合を確かめ、貢献全体に責任を負うことが求められます。
AI支援による不具合の発見と修正では、軽微でない問題について再現用のプログラムなどを作り、実在する不具合かを検証する手順が定められています。修正の作成も原則として必須で、ビルドしたうえで、再現手順や再解析によって修正の効果を確かめる必要があります。新たなビルド警告を出さず、パッチの形式などを検査する「checkpatch.pl」にも合格することが条件です。
貢献の出所などを証明する開発者原産地証明書「DCO」への署名に相当する「Signed-off-by」は、人間だけが付けられます。ビルドやテスト、再現手順の作成ができなかった場合には、その内容を明示することも求められます。
curlでは不正確な報告の負担から報奨金終了へ
Linuxで修正の進展が語られる一方、不正確な報告への対応に負担を抱えるオープンソースの事例もあります。データ転送用ツール「curl」の創設者ダニエル・ステンバーグ氏は、2025年7月時点で、2025年のセキュリティー報告は週平均約2件あり、7月初めまでに本物の脆弱性と判明した割合は約5％だったと述べていました。
当時のcurlのセキュリティーチームは7人で、1件の報告を3〜4人が確認し、30分〜3時間を要していました。報告者には生成AIの使用を開示し、AIが示した事実や主張を再確認することを求めていました。
その後、curlは2026年1月末で脆弱性報告への報奨金制度を終了する方針を示しました。ステンバーグ氏は、調査が不十分な報告を送る動機を減らし、セキュリティーチームの負担を軽くする狙いだと述べています。
移行にあたっては、2026年1月31日までHackerOne経由の報告を受け付け、処理中の案件には引き続き対応する計画としました。2月1日以降の新規報告はGitHubへ直接送る方式に切り替え、脆弱性報告への金銭的な報酬は提供しない方針です。
