Linuxカーネル、AI支援バグ報告を公開扱いに

Linuxカーネル7.1のドキュメントに、脅威モデルと「セキュリティバグとは何か」を定義する新規文書が加わった。AI支援で見つけたバグは原則として公開扱い、というカーネル開発陣の苦渋の答えがここに刻まれている。

docs-7.1-fixesに紛れ込んだ大物

リーナス・トーバルズ（Linus Torvalds）が日本時間2026年5月16日にマージしたタグ docs-7.1-fixes は、見出しだけ眺めれば地味な文書修正パッチに見える。ドキュメント担当のジョナサン・コルベット（Jonathan Corbet）からのプルリクエストで、コミット数は5本、変更行数は340行追加・2行削除。コミット履歴の流れの中では小粒に映る。

その中身は、カーネル開発の運用ルールそのものを書き換える内容だった。新規ファイル Documentation/process/threat-model.rst が235行まるごと追加され、既存の security-bugs.rst にも100行を超える追記が入っている。執筆したのはHAProxy開発者にしてLinuxカーネルメンテナのウィリー・タロー（Willy Tarreau）。

トーバルズは自身のマージ説明で、コルベットからのプルリクを次のように要約している。

ウィリー・タローによる新文書、セキュリティバグの定義と扱い方を明確化するもの。バグ報告者の一部にしっかり読んでもらいたいので、急いで世に出すことにした。

「急いで世に出した」という言葉の裏には、ここ1年でカーネル開発現場が直面した混乱がある。

「週2、3本」が「日に5〜10本」になった

ウィリー・タローは今年4月、別の場でこう書いていた。2年前は週2、3本だったセキュリティリストへの報告が、1年前には週10本に増え、年明けからは日に5〜10本に達している、と。

数字だけ追うと量の話に見える。タローの言葉で重要なのはその先で、「内容の大半は正しい」と認めている点だ。グレッグ・クローハートマン（Greg Kroah-Hartman）も3月、AIによるバグ報告の質に変曲点が訪れたと述べていた。スロップ（AIが吐き出した低品質な出力）として無視できた時代は終わり、本物のバグレポートが洪水のように届いている。

問題はそこから派生する。同じバグを別の人間が別のツールで見つける、という重複報告が日常化しているのだ。タローいわく「これまで一度もなかった現象」。AIアシスタントの利用者が増え、似たような巡回経路でコードを舐めるので、同じ穴に同時に複数のレポーターが落ちる。

カーネル側の対応として、まずは「AI支援で見つけたバグは公開として扱え」という方針が打ち出された。

AI支援＝公開、という新ルール

新設された脅威モデル文書とは別に、security-bugs.rst には次の一文が太字で書き加えられた。

AIアシスタントの力を借りてバグを特定したのであれば、それは公開バグとして扱わなければならない。

理由は単純で、上の重複報告の実態に根拠を置いている。「複数の研究者が同じ日にほぼ同時に同じバグを発見する事例が、システマティックに観測されている」とドキュメントは説明する。1人が秘密裏に報告しても、別の誰かがすでに同じ穴を見つけているか、その日のうちに見つける。embargo（公表猶予）を敷いて段取りを組むこと自体が機能しない。

再現コードについては別扱いになる。公開リストに流れる以上、再現手順そのものをばらまけば攻撃材料を提供することになるため、「ある旨だけ伝える」運用が推奨される。必要に応じてメンテナが個別に求める、という段取りだ。

加えて、linux-distros のような事前共有リストへの通知ルートも、AI支援ツールの使用が「公開扱いとすべき理由」に正式に追記された。広く入手可能な自動脆弱性スキャナの結果と同列に置かれたことになる。

「これはセキュリティバグではない」を明文化する

タローが書き下ろした新文書 threat-model.rst のもう一つの柱は、何が脆弱性で何がそうでないかを線引きする作業だ。

カーネルチームがセキュリティリストで受け取る報告の多くは、本来なら通常のバグ報告チャネル（reporting-issues.rst）に送るべき内容だった、と文書は書く。「セキュリティ報告に分類すれば早く対応してもらえる」という誤解は、トリアージ能力を消費するだけで結果として他の本物の報告を遅らせる。

文書は「セキュリティバグではないもの」を6カテゴリに整理した。設定の問題（サポート切れカーネル、CONFIG_NOMMU のように意図的に保護を下げるビルド、debugfs への書き込みを許す管理者操作、KASAN などのデバッグ機能で初めて顕在化するバグ、staging扱いのドライバ）、権限超過の問題（すでに CAP_SYS_ADMIN を持つユーザがカーネルを落とせる、というたぐい。root権限を持つ者が自分の権限内で起こせる事象は脆弱性ではない）、実環境外の問題（ラボ条件でしか成立しない確率的攻撃、数十億回のブルートフォース、現実には存在しない数千万スレッドのシミュレーション）、ハードニング失敗（ASLR回避単体、明確な悪用経路を伴わない情報漏洩）、ランダムな情報リーク（構造体パディング、エラーメッセージに混入する識別子断片、カーネルアドレスのリーク自体は修正対象ではあるが脆弱性とは扱わない）、細工されたファイルシステムイメージ（root権限でマウントすればクラッシュする、というのは前提が崩れている）。この6つが「セキュリティ案件ではない」と明示された。

ハードウェアが仕様通りに動作することを、カーネルは前提とする。CPUバグやサイドチャネル、ハードウェアが想定外の入力に対して見せる挙動など、ハードウェアが仕様通りの分離を維持できない場合、カーネルはベストエフォートで緩和策を実装する。これらは攻撃面の縮小やコスト引き上げのための措置であり、カーネルが提供する安全保証ではない。

この一文で、SpectreやMeltdown系の派生報告に対する立場が改めて明文化されたことになる。

AI報告者への「お作法」要求

新文書の中でひときわ実務的なのが、Responsible use of AI to find bugs の節だ。AI支援のレポート提出者に向けて、メンテナが疲弊しないための要求が並ぶ。

長さでは、AI生成レポートは無駄に長くなりがちで、影響ファイル・対象バージョン・実害の核心が複数ページの後ろに埋もれるため、冒頭で要約を出せと求めている。書式は、Markdown装飾を剥がしてプレーンテキストで送ること。引用や転送のたびに崩れるからだ。影響評価では、脅威モデルを理解しないまま「理論上の影響」を膨らませるなと釘を刺す。「あらゆるユーザが CAP_NET_ADMIN を取得できる」のような検証可能な事実だけを書け、というわけだ。再現コードはツールに作らせたうえで動かして確認しろと指示があり、動かないなら報告の妥当性そのものを疑えと付け加えている。修正案については、AIはコード評価より生成の方が得意な場合があるので、修正パッチも作らせて動作確認しろという要求になっている。Fixes: タグを付ける作法も守ること、と細かい。

文書は最後に冷たく付け加える。要件を満たさないレポートは無視されるリスクがある、と。

加えて、対象ファイルが1年以上更新されておらずメンテナが1人しかいないなら、影響を受けるユーザは実質的に存在しない、という現実論も書き込まれた。古いハードウェア向けドライバや使われていないファイルシステムのAI発掘バグは、メンテナの時間を消費するに値しない、という線引きである。

「公開リストに送れ」という選別

通知ルートも整理された。これまで受信者が2人以下のメッセージはセキュリティチームを Cc: する運用だったが、今後は次のように切り分ける。

受信者が2人以下なら、引き続きセキュリティチームを必ずCc:する。大規模なメンテナチームに送る場合は、最初の数回または対応に詰まったときだけCc:すればよい。手順に慣れたあとは大規模チームに送るときセキュリティリストへのCc:は不要。

セキュリティリストの負荷を下げ、本来の役目（少人数メンテナへの手続き支援）に集中させる調整だ。

「不確かなら非公開で送れ」と書き残した理由

文書の中で、ややトーンが柔らかい一文がある。

どちらに振るべきか迷ったら、非公開での報告を選んでほしい。境界線上の報告をトリアージする方が、本物の脆弱性を見逃すよりましだから。

AI支援バグの扱いを公開寄りに振り、お作法を要求し、線引きを明文化する。それでもこの一文を残したところに、カーネル開発陣の現実認識が透けて見える。洪水を捌くために運用は厳しくする、本物を取り逃がす道までは塞がない、という姿勢だ。

タローはHAProxyを2001年に書き始め、2006年からLinuxカーネルの長期保守版メンテナを務めてきた20年戦士だ。LWNやKernel Recipesの場でカーネル開発の流儀を語ってきた人物が、いまAIエージェントに向けて文書を書いている。技術の流れがここ1年で何を変えたか、その答えが一篇のドキュメントに凝縮されている。

技術文書は退屈なものだ。たまにそこへ、運用が大きく曲がる瞬間が記録される。今回のdocs-7.1-fixesは、その一例として残るはずだ。

参照元

• Linux kernel git - Merge tag 'docs-7.1-fixes' (commit 36d49bba)

関連記事

• Linux 7.1-rc4公開、AIのバグ報告にカーネル開発者が線引き
• AIのバグ報告で機能停止寸前、リーナス・トーバルズが嘆くLinuxの現状
• Linuxカーネルにキルスイッチ案、未修正脆弱性に対応
• Linux 7.1-rc3公開、カーネル肥大は「新常態」だ
• トーバルズ、Linux 7.1で2件のプルリクエストを差し戻し
• RustとAIで1からX11サーバーを書き直す。yserverが問いかけるもの
• rsyncのAIコーディング騒動が映すもの――30年のインフラを支える「一人」の限界
• Linux 7.1-rc6、AI修正の波は収まらず
• Linuxに19年潜んだ権限昇格の欠陥が発覚
• QEMU、AI生成コードの「全面禁止」から限定許可へ