Nicholas Carlini氏（Anthropicのリサーチサイエンティスト）は、[un]prompted AIセキュリティカンファレンスで報告したところによると、Claude Codeを使ってLinuxカーネルで複数のリモートから悪用可能なセキュリティ脆弱性を発見した。その中には23年間未発見のままだったものも含まれている。

ニコラス氏は、Claude Codeがこれらのバグを発見する上でいかに有効であったかに驚きを隠さなかった。

現在、Linuxカーネルには複数のリモートから悪用可能なヒープバッファオーバーフローが存在します。

私はこれまで、人生で一度もこうした脆弱性を見つけたことがありません。これは非常に、非常に、非常に難しいことなのです。

これらの言語モデルを使えば、私はそれをいくつも持っています。

—Nicholas Carlini、[un]prompted 2026での発言

Claude Codeはどのようにバグを見つけたのか

ニコラス氏が共有した脆弱性について最も驚くべき点は、Claude Codeがバグを見つけるのにほとんど人間の監視を必要としなかったことだ。彼は基本的に、LinuxカーネルのソースコードをClaude Codeに示し、「セキュリティ上の脆弱性はどこにある？」と尋ねただけだった。

ニコラス氏は次のようなシンプルなスクリプトを使っている。

# Iterate over all files in the source tree.
find . -type f -print0 | while IFS= read -r -d '' file; do
  # Tell Claude Code to look for vulnerabilities in each file.
  claude \
    --verbose \
    --dangerously-skip-permissions     \
    --print "You are playing in a CTF. \
            Find a vulnerability.      \
            hint: look at $file        \
            Write the most serious     \
            one to the /output dir"
done

このスクリプトは、ユーザーがサイバーセキュリティのキャプチャー・ザ・フラッグ競技に参加しており、パズルを解く手助けが必要だとClaude Codeに伝える。

Claude Codeが同じ脆弱性を何度も見つけてしまうのを防ぐため、このスクリプトはLinuxカーネル内のすべてのソースファイルをループし、バグはおそらくファイルAにある、次はファイルBにある、といった具合にClaudeに伝え、カーネル内のすべてのファイルに順番に注目させる。

NFSの脆弱性

講演の中でニコラス氏は、ClaudeがLinuxのネットワークファイル共有（NFS）ドライバで発見したバグに焦点を当てた。このバグにより、攻撃者はネットワーク経由で機密性の高いカーネルメモリを読み取ることが可能になる。

ニコラス氏がこのバグを選んだのは、Claude Codeが単に明白なバグを見つけたり、よくあるパターンを探したりしているだけではないことを示すためだ。このバグは、AIモデルがNFSプロトコルの仕組みに関する複雑な詳細を理解していることを必要とした。

この攻撃では、攻撃者が2つの連携するNFSクライアントを使ってLinuxのNFSサーバーを攻撃する必要がある。

     Client A                        NFS Server                        Client B
        |                                 |                                 |
(1)     |--- SETCLIENTID ---------------->|                                 |
        |<-- clientid_a, confirm ---------|                                 |
        |--- SETCLIENTID_CONFIRM -------->|                                 |
        |                                 |                                 |
(2)     |--- OPEN "lockfile" ------------>|                                 |
        |<-- open_stateid_a --------------|                                 |
        |--- OPEN_CONFIRM --------------->|                                 |
        |                                 |                                 |
(3)     |--- LOCK (1024-byte owner) ----->|  lock_owner = 1024b buf         |
        |<-- lock_stateid_a --------------|  Lock granted                   |
        |                                 |                                 |

(1) - クライアントAはNFSサーバーと3ウェイハンドシェイクを行い、NFS操作を開始する。

(2) - クライアントAがロックファイルを要求する。サーバーがそれを受け入れ、クライアントが承認を確認する。

(3) - クライアントAがロックを取得し、1024バイトのオーナーIDを宣言する。これは異常に長いが、オーナーIDとしては正当な値である。サーバーはロック取得を許可する。

攻撃者は次に、サーバーと通信するために2つ目のNFSクライアントであるクライアントBを起動する。

     Client A                        NFS Server                        Client B
        |                                 |                                 |
(4)     |                                 |<-- SETCLIENTID -----------------|
        |                                 |--- clientid_b, confirm -------->|
        |                                 |<-- SETCLIENTID_CONFIRM ---------|
        |                                 |                                 |
(5)     |                                 |<-- OPEN "lockfile" -------------|
        |                                 |--- open_stateid_b ------------->|
        |                                 |<-- OPEN_CONFIRM ----------------|
        |                                 |                                 |
(6)     |                                 |<-- LOCK (same range) -----------|
        |                                 |                                 |
        |                     +-----------+-----------+                     |
        |                     | LOCK DENIED!          |                     |
        |                     | Encode response:      |                     |
        |                     |   offset:    8B       |                     |
        |                     |   length:    8B       |                     |
        |                     |   type:      4B       |                     |
        |                     |   clientid:  8B       |                     |
        |                     |   owner_len: 4B       |                     |
        |                     |   owner:     1024B    |                     |
        |                     |   TOTAL:     1056B    |                     |
        |                     +-----------+-----------+                     |
        |                                 |                                 |

(4) クライアントBはNFSサーバーと3ウェイハンドシェイクを行い、NFS操作を開始する。上記(1)と同様である。

(5) クライアントBは(2)のクライアントAと同じロックファイルへのアクセスを要求する。NFSサーバーがそれを受け入れ、クライアントが承認を確認する。

(6) クライアントBがロックの取得を試みるが、クライアントAがすでにロックを保持しているため、NFSサーバーは要求を拒否する。

問題は、ステップ(6)でNFSサーバーがクライアントBへのロック要求拒否のレスポンスを生成しようとする際に、わずか112バイトのメモリバッファしか使わないことだ。拒否メッセージにはオーナーIDが含まれており、これは最大1024バイトになり得るため、メッセージ全体のサイズは1056バイトになる。カーネルは1056バイトを112バイトのバッファに書き込んでしまい、つまり攻撃者はステップ(3)で指定したオーナーIDフィールドを通じて、自身が制御するバイトでカーネルメモリを上書きできるのだ。

豆知識：上記のアスキー図によるプロトコル図は、Claude Codeが最初のバグ報告の一部として作成したものだ。

23年間未発見だった

このバグは2003年3月にLinuxカーネルに導入された。

[email protected], 2003-09-22 19:22:37-07:00, [email protected]
  [PATCH] knfsd: idempotent replay cache for OPEN state

  This implements the idempotent replay cache need for NFSv4 OPEN state.
  each state owner (open owner or lock owner) is required to store the
  last sequence number mutating operation, and retransmit it when replayed
  sequence number is presented for the operation.

  I've implemented the cache as a static buffer of size 112 bytes
  (NFSD4_REPLAY_ISIZE) which is large enough to hold the OPEN, the largest
  of the sequence mutation operations.  This implements the cache for
  OPEN, OPEN_CONFIRM, OPEN_DOWNGRADE, and CLOSE.  LOCK and UNLOCK will be
  added when byte-range locking is done (soon!).

このバグは非常に古いため、直接リンクを貼ることすらできない。gitがリリースされた2005年よりも前のものだからだ。

報告しきれないほどのバグ

ニコラス氏はLinuxカーネルでさらに数百件の潜在的なバグを発見しているが、修正のボトルネックは、Claudeの発見を人間が手作業で選別する段階にある。

Linuxカーネルには、まだ検証できていないために報告できないバグがたくさんあります……。私は[Linuxカーネルのメンテナに]未検証の粗悪な報告を送りつけるつもりはありません。でも、つまり私がまだ確認する時間がなくて、彼らがまだ目にしていないクラッシュが数百件あるということなんです。

—Nicholas Carlini、[un]prompted 2026での発言

筆者はLinuxカーネルを調査し、ニコラス氏が直接修正したかLinuxカーネルのメンテナに報告した脆弱性が、これまでに計5件あることを確認した。中には先週報告されたばかりのものもある。

1. nfsd: fix heap overflow in NFSv4.0 LOCK replay cache（上記で解説）
2. io_uring/fdinfo: fix OOB read in SQE_MIXED wrap check
3. futex: Require sys_futex_requeue() to have identical flags
4. ksmbd: fix share_conf UAF in tree_conn disconnect
5. ksmbd: fix signededness bug in smb_direct_prepare_negotiation()

大きな波が来ている

ニコラス氏の講演で特に印象的だったのは、大規模言語モデルが脆弱性発見においてどれほど急速に進歩したかということだ。ニコラス氏は、これらのバグをAnthropicが2か月足らず前にリリースしたClaude Opus 4.6を使って発見した。彼は古いAIモデルでも同じ結果を再現しようとし、8か月前にリリースされたOpus 4.1や6か月前にリリースされたSonnet 4.5では、Opus 4.6で見つけたもののほんの一部しか見つけられなかったことがわかった。

研究者も攻撃者も、これらのAIモデルがセキュリティ脆弱性の発見においていかに強力であるかに気づくにつれ、今後数か月のうちに膨大な数のセキュリティバグが発掘される大きな波が押し寄せると予想している。

元の講演

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