Linux Daily Topics

Linuxカーネルの論理バグ“Copy Fail”示した論理バグとゼロコピーの危険な連鎖

2026年4月30日付けで公開されたLinuxカーネルの脆弱性「CVE-2026-31431」―通称⁠Copy Fail⁠は、ローカルユーザが非常に簡単な方法でroot権限を奪取できてしまうことに加え、2017年以降にリリースされたほぼすべてのLinuxカーネル/ディストリビューション(Linux 4.14以降)が影響を受けるという対象範囲の広さから、世界中のLinuxユーザに衝撃を与えた。Copy Failを発見した韓国のサイバーセキュリティ企業Theoriは3月23日にLinuxカーネルセキュリティチームに脆弱性を報告、その後、メインラインへのパッチのコミットや主要ディストリビューションの対応が終了してからこの脆弱性の詳細を公開している。

Copy Failはシステムの運用やテストの実行時において発見されたのではなく、TheoriのセキュリティリサーチャーであるTaeyang Leeの洞察をきっかけに発見されたLinuxカーネルの論理バグである。LeeはLinuxカーネル内の暗号化API「AF_ALG」ソケットを研究しているうちに、AF_ALGとsplice()システムコール(Linuxカーネルが提供するゼロコピー型の高速データ転送API)を組み合わせることで、特権をもたないユーザ空間からでも/usr/bin/suなどの重要なrootプログラムのページキャッシュ(ディスクファイルをメモリ上にキャッシュした領域)のデータを暗号化サブシステムに直接供給できる経路を作れることに気がついた。エクスプロイトが書き換えたページキャッシュのサイズはわずか4バイトだが、これだけでもsetuidバイナリの実行フローを書き換えるには十分だった。

Theoriは「Xint Code」というLLMを活用した静的アプリケーションセキュリティテスト(SAST)プラットフォームを提供しており、2026年2月にはPostgreSQLに20年以上ひそんでいた脆弱性(CVE-206-2005)を発見したことで知名度を大きく上げた。Leeの洞察の可能性を確かめるため、Theoriの開発者たちはXint Codeの「オペレータプロンプト」機能を使い、以下のような指示を行った。

これはLinuxのクリプト/サブシステムです。ユーザ空間のシステムコールから到達可能なすべてのコードパスを調べてください。重要な点として、splice()は読み取り専用ファイル(setuidバイナリを含む)のページキャッシュ参照をcrypto TXスキャッターリスト(暗号化処理用のスキャッターリスト)に渡すことができることに注意してください。

This is the linux crypto/ subsystem. Please examine all codepaths reachable from userspace syscalls. Note one key observation: splice() can deliver page-cache references of read-only files (including setuid binaries) to crypto TX scatterlists

この指示から1時間後、Xint Codeはスキャンを完了し、Copy Failを出力した。つまりCopy FailはLeeの洞察によって得られた仮説を、Xint CodeチームがLLMベースのSASTで大規模検索を実施したことで発見された脆弱性ということになる。

“コピー”が持つ隠れた意味

Copy Failのケースは、Linuxカーネルという膨大なコードベースにひそむ論理バグのリスクをあらためて浮き彫りにしたといえる。論理バグはバッファオーバーフローのようなメモリ破壊系のバグとは異なり、コンパイルエラーや強制終了などは発生せず、プログラムは最後まで実行される。しかし、実際にはコードに論理的な欠陥(アルゴリズムの不備、計算式やループの誤り、比較条件のミスなど)が含まれているため、設計者が意図しない動作や結果をともなうことになる。

Copy Failの場合は「読み取り専用ページは変更されない」⁠コピー後は独立している」というカーネル内部の前提が破綻していた。しかしコンパイルは正常に通ってしまうため、論理バグの発見は容易ではなく、サイバーセキュリティの観点からも重大なリスクとなりやすい。Copy Failを発見したTheoriのブログにも「Copy Failはごく単純な論理的欠陥であり、競合状態、再試行、クラッシュしやすいタイミングウィンドウなどに関係なく発生する」と書かれている。

また、Linuxカーネルはここ数年、splice()のように「コピーをできるだけ避けて同じメモリを共有する」技術を採用することでパフォーマンスの高速化を図る傾向にあるが、このことは状態管理の複雑化とセキュリティ上のリスク拡大を招く。たとえばio_uringもコピー削減と共有メモリの活用によってパフォーマンスの拡大を図るしくみだが、その複雑さは脆弱性攻撃の対象となりやすいことも指摘されている。

コピーは単なるデータ転送ではなく、信頼の境界(カーネル空間とユーザ空間)を分離するという安全機構でもある。だがsplice()のようなゼロコピー技術の普及はその境界をあいまいにしやすく、論理バグが重大な脆弱性へと発展するリスクを高めていく。Linuxカーネルに対する高速化の要求は今後さらに強まっていくとみられるが、しかしその一方で、ユーザ空間とカーネル空間の境界をいかに安全に保っていくかもまた、今後のカーネル開発における重要なカギだといえるだろう。

おすすめ記事

記事・ニュース一覧