Claude Codeが23年間潜んでいたLinuxカーネルのヒープバッファオーバーフローを発見した

Anthropicのリサーチサイエンティスト Nicholas Carlini が、自社のClaude Code（モデルはClaude Opus 4.6）を使ってLinuxカーネルのNFS（Network File System）ドライバに23年間潜んでいたリモート悪用可能なヒープバッファオーバーフローを発見した。mtlynch.ioの技術記事が詳細な経緯と技術的内容を公開しており、Hacker Newsでも大きな反響を呼んだ。

Carliniは「リモートから悪用できるヒープバッファオーバーフローは、自分の人生で一度も見つけたことがなかった。これを見つけるのは本当に、本当に難しい」と述べている。5件の脆弱性がLinuxカーネルに報告され、AIによるコードレビューが人間の長年の目を超えた事例として大きく報じられた。

だが、少し引いて見るとこれはAnthropicの社員がAnthropicのモデルで成果を出した話だ。カーネル全体をOpusクラスで走査するのにどれだけトークンを燃やしたのか、一般ユーザーと同じレート制限や課金の下でやったのか。発見の技術的インパクトは本物だが、それを実現できたリソースの非対称性も無視できない。

発見の手法

Carliniのアプローチは驚くほどシンプルだった。シェルスクリプトでLinuxカーネルのソースファイルを順番にイテレートし、各ファイルをClaude Codeに渡して脆弱性を探させた。ポイントは2つある。

1つ目は、ファイル単位で逐次的にスキャンしたこと。モデルに複数ファイルをまとめて渡すと同じバグに繰り返しフォーカスしてしまう傾向があるため、1ファイルずつ独立して分析させることで網羅性を確保した。

2つ目は、プロンプトにCTF（Capture The Flag）のフレーミングを採用したこと。「このコードの脆弱性を見つけてください」ではなく、CTF競技のように「フラグを獲得せよ」という文脈でタスクを与えることで、モデルがより徹底的に脆弱性を探索するよう誘導した。

この手法は、Anthropicが2月に発表した Claude Code Security のAI推論ベース脆弱性検出と同じ方向性にある。Claude Code Securityが「人間のセキュリティ研究者のようにコードを読む」推論ベースのアプローチを取っているのと同様、Carliniの手法も既知パターンのスキャンに頼らず、モデル自身の推論能力に依存している。

NFSv4.0 LOCK応答キャッシュのヒープオーバーフロー

発見された脆弱性の核心はバッファサイズの不整合だ。

NFSv4.0のnfsd（NFSデーモン）には、LOCKリクエストの応答をキャッシュして再送時に再利用するリプレイキャッシュ機構がある。このキャッシュに割り当てられるバッファサイズは NFSD4_REPLAY_ISIZE で定義された112バイトの固定長だった。

問題は、LOCK拒否応答にはロックオーナーのIDフィールドが含まれること。NFSの仕様上、オーナーIDは最大1,024バイトまで許容される。つまりLOCK拒否応答の最大ペイロードサイズは1,056バイトに達する。112バイトのバッファに1,056バイトを書き込めば、当然カーネルヒープ上の隣接メモリを破壊する。

項目	サイズ
リプレイキャッシュバッファ	112バイト
オーナーIDの最大長	1,024バイト
LOCK拒否応答の最大サイズ	1,056バイト
オーバーフロー量	最大944バイト

このバグは2003年3月、カーネルバージョン2.6.0-test5でNFSv4.0のステート管理コードが導入された時点から存在していた。OPENステートのリプレイキャッシュ用に設計されたバッファが、そのままLOCKオペレーションにも流用されたことが原因だ。OPENの応答は112バイトに収まるが、LOCKの応答は可変長のオーナーIDを含むため収まらない。23年間、誰もこの不整合に気づかなかった。

攻撃の流れ

この脆弱性を悪用するには、2つのNFSクライアントが協調して動作する必要がある。

graph TD
    A["クライアントA<br/>NFSサーバーに接続"] --> B["クライアントA<br/>ファイルFにLOCKを取得<br/>オーナーID: 短い値"]
    B --> C["クライアントB<br/>同じファイルFにLOCKを要求<br/>オーナーID: 1024バイトの値"]
    C --> D["NFSサーバー<br/>LOCK拒否応答を生成<br/>クライアントBのオーナーIDを含む"]
    D --> E["リプレイキャッシュに書き込み<br/>112バイトバッファに1056バイト"]
    E --> F["ヒープオーバーフロー発生<br/>隣接するカーネルメモリを破壊"]
    F --> G["攻撃者がカーネルメモリを<br/>リモートから読み取り可能"]

攻撃者はオーナーIDフィールドを制御できるため、書き込まれるバイト列も制御可能だ。これはネットワーク経由でリモートから実行でき、NFSを公開しているLinuxサーバーすべてが潜在的な攻撃対象になる。

パッチはLinuxカーネルのgitにコミット済みだ。

NFSとは何か

NFS（Network File System）はSun Microsystemsが1984年に開発したネットワークファイル共有プロトコルで、リモートのファイルシステムをローカルにマウントして透過的にアクセスする仕組みだ。Linuxのnfsdはカーネルモジュールとして実装されており、カーネル空間で動作する。つまりnfsdの脆弱性はカーネルレベルの権限で悪用される。

NFSの主要バージョンは以下の通り。

バージョン	年	主な特徴
NFSv2	1989	最初の広く使われたバージョン。UDP/TCP
NFSv3	1995	非同期書き込み、大ファイル対応
NFSv4.0	2003	ステートフル。ファイルロック統合、Kerberos認証
NFSv4.1	2010	pNFS（並列NFS）でスケーラビリティ向上
NFSv4.2	2016	サーバーサイドコピー、ラベルドNFS

今回の脆弱性はNFSv4.0で導入されたステートフルなロック管理機構に固有のものだ。NFSv3以前はファイルロックを別プロトコル（NLM）で扱っていたため、このリプレイキャッシュの問題は存在しない。

ヒープバッファオーバーフローの仕組み

ヒープバッファオーバーフローは、動的に確保されたメモリ領域（ヒープ）に対して、確保したサイズを超えるデータを書き込むバグだ。スタックバッファオーバーフローと並んでC言語プログラムの代表的な脆弱性カテゴリに属する。

スタックオーバーフローではリターンアドレスを上書きしてコード実行を奪うのが典型的な攻撃パスだが、ヒープオーバーフローでは隣接するヒープチャンクのメタデータや、同じヒープ上に確保された他のカーネルオブジェクトを破壊する。攻撃者が書き込むバイト列を制御できる場合、カーネルの関数ポインタを上書きして任意コード実行に持ち込むことも理論上は可能だ。

今回のケースでは、攻撃者はオーナーIDの1,024バイトを自由に設定できるため、隣接メモリへの書き込み内容をほぼ完全に制御できる。加えて、オーバーフロー後のメモリ内容がNFS応答としてネットワーク経由で返されるため、カーネルメモリの内容をリモートから読み取る情報漏洩にも使える。

5件の脆弱性が報告された

Carliniの走査で見つかったのはNFSの件だけではない。合計5件の脆弱性がLinuxカーネルメンテナーに報告されている。

脆弱性	コンポーネント	概要
NFSv4.0 LOCKリプレイキャッシュのヒープオーバーフロー	nfsd	今回の主題。リモート悪用可能
io_uring/fdinfo OOB read	io_uring	SQE_MIXEDラップ時の境界外読み取り
sys_futex_requeue() フラグ検証不備	futex	リクエストフラグの検証が不十分
share_conf use-after-free	ksmbd	ツリー接続切断時の解放済みメモリ参照
smb_direct_prepare_negotiation() 符号問題	ksmbd	符号付き/符号なし整数の比較ミス

ksmbd（カーネル内SMBサーバー）で2件見つかっている点も興味深い。ksmbdはNFSのnfsdと同様にカーネル空間で動作するネットワークファイル共有の実装で、複雑なプロトコル処理をカーネルモードで行うためにバグが潜みやすい領域だ。

モデル間の能力差

Carliniは複数のClaudeモデルで同じスキャンを実行し、モデル間の能力差も検証している。

Claude Opus 4.6は複数の脆弱性を発見したが、Claude Opus 4.1やClaude Sonnet 4.5では発見数が大幅に少なかったという。モデルの世代間で、コードの文脈理解と脆弱性パターンの認識精度に明確な差がある。

これはGoogleが Sashiko で示したデータとも符合する。SashikoはLinuxカーネルのパッチレビューにAIを適用し、人間のレビューをすり抜けた既知バグの53.6%を検出した。ただしSashikoはパッチ（差分）のレビューが主であるのに対し、Carliniの手法はソースファイル全体を対象にした脆弱性ハンティングであり、アプローチが異なる。

Anthropicの社員がAnthropicのモデルで見つけたという構図

技術的な発見は本物だが、この話の構図は意識しておいたほうがいい。

Carliniは著名なMLセキュリティ研究者で、学術的な動機でやっているのだろう。だが結果として、Anthropicの社員がAnthropicの最上位モデルで誰もが注目する成果を出し、それが技術メディアで大々的に取り上げられた。自社のモデル能力を世間に見せつけるデモンストレーションとしてこれ以上ない流れだ。

意図的にそう仕組んだとまでは言わない。ただ、この種の「自社ツールで凄いことができました」は、研究成果であると同時にマーケティング素材でもある。GoogleのSashikoもProject Zero出身者が関わっていて似た構図ではあるが、あちらはGemini単体の宣伝色はここまで強くなかった。

もう一つ気になるのは、これがどの程度組織的に行われているのかという点だ。Carliniの個人的な研究プロジェクトとして紹介されているが、Anthropicが社内でこうしたカーネル走査を日常的にバックグラウンドで回しているのか、それともCarliniが個人の裁量で試したのかは外部からは見えない。「数百件の未検証クラッシュが溜まっている」という規模のスキャンを回せている時点で、個人の趣味プロジェクトにしてはリソースが潤沢すぎる。

一般ユーザーがやるとどうなるか

手法自体は再現できる。シェルスクリプトでファイルをイテレートしてClaude Codeに渡すだけで、特殊なツールもインフラも要らない。問題はコストだ。

Linuxカーネルのソースツリーには7万以上のファイルがある。これを1ファイルずつClaude Opus 4.6に渡して脆弱性分析させると、トークン消費量は膨大になる。API直接利用の場合、Opusクラスのモデルはトークン単価が最も高く、カーネル全体のスキャンでは数千ドル規模のAPI費用が発生してもおかしくない。

Claude Codeをサブスクリプションで使う場合はさらに厳しい。Pro（月額$20）では数十ファイルも分析すれば使用量の上限に達する。Max（月額$100〜$200）でも、7万ファイルの逐次スキャンを完走させるには到底足りない。一般ユーザーが同じことをやろうとしたら、上限に引っかかって止まるのがオチだ。

Anthropicの社員である以上、社内のAPIアクセスに外部ユーザーと同じレート制限や課金が適用されているとは考えにくい。「まだ検証できていないクラッシュが数百件溜まっている」とCarliniは述べているが、数百件の結果が出るほどの走査を回せている時点で、一般ユーザーとは前提条件が根本的に違う。事実上無制限のリソースを持つ研究者が自社の最上位モデルをフル稼働させた結果であり、同じことを外部から再現しようとすればかなりの出費を覚悟する必要がある。

graph LR
    A["Anthropic社員"] --> B["社内APIアクセス<br/>レート制限なし?<br/>課金なし?"]
    B --> C["7万ファイル走査<br/>数百件のクラッシュ検出"]
    D["一般ユーザー"] --> E["Pro: 月$20<br/>Max: 月$100〜200"]
    E --> F["数十〜数百ファイルで<br/>使用量上限に到達"]

検証のボトルネックは人間の側にある

Carliniが指摘しているもう一つの問題は、AIの発見能力ではなく人間の検証能力がボトルネックになっていることだ。「Linuxカーネルに未報告のバグが大量にある。まだ検証できていないクラッシュが数百件溜まっている」と述べている。

AIがコードを読んで怪しい箇所を指摘するスピードは、人間がそれを再現・検証・報告するスピードを大幅に上回っている。AIが検出を担い、人間がトリアージ（優先度判定と振り分け）と修正に集中する分業は、もう始まっている。

ただし、AIの脆弱性発見能力は攻撃側にも同じように使える。Claude全ティアがジェイルブレイクされたAFL攻撃の件が示すように、安全性ガードレールの突破も現実の脅威だ。

発見そのものはすごい。23年間見つからなかったリモート悪用可能なヒープオーバーフローをAIが掘り当てたのは事実だ。ただ、「AIがカーネルの脆弱性を見つけた」というヘッドラインの裏には、Anthropicの社員がAnthropicのリソースでやったという文脈がある。研究成果であると同時に、自社モデルの能力を世間に印象づける格好の材料でもある。

カーネル全体を走査する必要はない。自分のプロジェクトの重要な部分に限定してClaude Codeに脆弱性を探させるだけでも、従来のSAST（静的アプリケーションセキュリティテスト）ツールでは拾えないロジックバグを見つけられる可能性はある。そのスケールならProやMaxの上限内でも回せる。カーネル全走査のスケール感に圧倒される必要はないが、同じことができると思う必要もない。