クロード・コードが23年間隠されていたLinuxの脆弱性を発見

2026年4月4日原文(mtlynch.io)

概要

Anthropic の研究者 Nicholas Carlini が Claude Code でLinuxカーネルの脆弱性を多数発見
23年間発見されなかった NFS脆弱性 も特定
シンプルなスクリプトでAIにソースコード解析を指示
見つかった脆弱性の多くは リモート攻撃可能な深刻なバグ
LLMの進化で今後さらに多くの脆弱性発見が予想される

Claude CodeによるLinuxカーネル脆弱性発見

Nicholas Carlini は Anthropic の研究者であり、 [un]prompted AIセキュリティカンファレンス で成果を発表
Claude Code を用いて、Linuxカーネルに複数のリモートから悪用可能な脆弱性を発見
23年間未発見だった NFSドライバのバグ も特定
Carlini自身も「この種のバグを見つけたのは初めて」と驚きを表明

Claude Codeによるバグ発見の方法

カーネル全ファイルをループ処理し、各ファイルごとに「脆弱性を探せ」とAIに指示するシンプルなスクリプトを使用
- 例: find . -type f -print0 | while ... claude ... "Find a vulnerability. ..."
CTF（Capture the Flag）競技を想定したプロンプトでAIに解析を促進
各ファイルごとに個別解析することで、同じバグの重複検出を回避

NFS脆弱性の詳細

問題箇所：Linuxの NFS（Network File System）ドライバ
攻撃者が2つのNFSクライアントを利用し、サーバへ特殊なリクエストを送ることで攻撃
バッファオーバーフロー ：サーバが112バイトのバッファに最大1056バイトを書き込む設計ミス
攻撃者が制御可能なデータでカーネルメモリを上書き可能
ASCIIプロトコル図もClaude Codeが自動生成

23年間未発見だった理由

バグの初出は 2003年3月、LinuxカーネルのNFSv4実装時
静的バッファサイズ （112バイト）に対し、設計上最大1024バイトのデータを格納する可能性
Git登場以前の古いコードであり、追跡も困難

大量の未報告バグ

Carliniはさらに数百件の潜在的バグを発見
- 手動検証が追いつかず、全てを報告できていない現状
既に修正・報告済みの主なバグ
- nfsd: NFSv4.0 LOCKリプレイキャッシュのヒープオーバーフロー修正
- io_uring/fdinfo: SQE_MIXEDラップチェックのOOBリード修正
- futex: sys_futex_requeue()に同一フラグ要件追加
- ksmbd: tree_conn切断時のshare_conf UAF修正
- ksmbd: smb_direct_prepare_negotiation()の符号誤り修正

LLMによる脆弱性発見の進化

Claude Opus 4.6 （リリース2ヶ月未満）で多数のバグを発見
旧モデル（Opus 4.1, Sonnet 4.5）では発見率が大幅に低い
今後、研究者や攻撃者によるバグ発見が急増する可能性

参考講演

Nicholas Carlini - Black-hat LLMs at [un]prompted 2026

Hackerたちの意見

「隠れている」ってわけじゃなくて、「誰も気にしなかった」って感じだね。1024バイトのオーナーIDを宣言してるけど、これはオーナーIDとしては異常に長いけど合法的な値なんだ。プロトコルを設計したり、可変長要素のコードを書くときは、「有効な長さの範囲は？」っていつも考えてる。112バイトのメモリバッファを使ってるんだけど、拒否メッセージには最大1024バイトのオーナーIDが含まれていて、メッセージの合計サイズは1056バイトになる。カーネルは112バイトのバッファに1056バイトを書き込む。これは多くの静的解析ツールが簡単に見つけられるものだよ。もちろん、LLMに「すべての固定サイズバッファを検査して」って頼むと、たくさんの幻覚が出てくるかもしれないけど、さらなる検査の出発点としてはいいかもね。

└

これは多くの静的解析ツールが簡単に見つけられるものだよ。それでも、20年以上も誰も見つけられなかったんだね（誰も実行しなかったか、見つけられなかったか、見つけたけど何百もの誤検知に埋もれてたか）。誰かがLLMでクールなことをするたびに、「それは簡単だった、重要じゃない、俺の親父でも寝てる間にできた」みたいな意見が出てくるのが面白い。

└

「隠れているわけじゃなくて、むしろ「誰も見ようとしなかった」って感じだね。」まあ、そうだね。見ようとする「誰か」が足りなかったんだ。OSSのバグを探すために時間をかけられる有資格者は限られているから、世界中でバグを見つける能力も限られていたんだ。少なくとも、そうだった。これらのモデルがバグを見つけて検証するのに十分な能力を持つようになってきたから、状況が変わってきているんだ。今やその限られたバグ発見能力が増えてきて、実際のバグが掘り起こされ始めている。今年は、モデルが能力を高め続ければ非常に面白いことになるだろうね。

「十分な目があれば、すべてのバグは浅い」これをアップデートする時が来たね：「100万トークンのコンテキストウィンドウがあれば、すべてのバグは浅い」

└

…そして誤検知をレビューするのに3ヶ月かかった。

└

すでに起こったこと: https://arxiv.org/abs/2407.08708

└

バグの中には浅いものもあれば、自動化ツールの信頼性の低さから生まれた誤検知の寄せ集めもあるよね。

これは驚くことじゃないね。言及されてないけど、Claude Codeも1000個の誤検知バグを見つけて、開発者たちはそれを排除するのに3ヶ月かかったんだ。

└

言及されてないけど、Claude Codeも1000個の誤検知バグを見つけて、開発者たちはそれを排除するのに3ヶ月かかったんだ。ソースは？どこにも見たことないよ。私の経験では、Claude Opus 4.6の脆弱性に対する誤検知率は20%を下回ってる。

└

PoCを書くようにすればよくない？

└

ここでの教訓は、Claude Codeが無駄だってことじゃなくて、正しい人の手にかかれば強力なツールになるってことだね。

└

静的/動的解析ツールは常に脆弱性を見つけてるよ。ある程度の規模のプロジェクトは、こういう退屈なスキャナーからの既知の問題が大量に溜まってる。問題は、それらを整理して優先順位をつけることなんだ。修正すべき問題が多すぎて、どれが悪用可能で実際にダメージを与えるのかを見極めるのは時間がかかる。古いバグをClaudeが見つけたからって感心する？まあ、ちょっとね…新しいスキャナーが導入されるたびに、他の人が見つけてない新しい発見があるから。

Hacker Newsで議論の続きを見る

ハクソク