Linux Kernel on KnightLiブログ

Copy Fail 脆弱性 CVE-2026-31431：Linux カーネルのファイルコピー経路におけるコンテナエスケープリスク

Fri, 01 May 2026 18:42:34 +0800

Copy Fail は Linux カーネルのファイルコピー経路に影響する脆弱性で、CVE-2026-31431 として管理されている。 Bugcrowd の分析では、これは注意すべきカーネルレベルの問題とされている。特定の条件下で、非特権ユーザーがファイルコピー関連のロジックを悪用し、不正な書き込みを引き起こせる可能性があり、その結果として権限昇格やコンテナエスケープにつながる。

リスクの観点では、これは通常のアプリケーション層の脆弱性ではない。問題はカーネルがファイルコピーとページキャッシュを処理する経路で発生するため、影響はコンテナ、共有ホスト、CI/CD Runner、PaaS プラットフォーム、マルチテナント Linux 環境にまで及ぶ。攻撃者がすでにシステム内で低権限コードを実行できる場合、この脆弱性は隔離境界を突破するための足がかりになり得る。

脆弱性はおおよそどこで発生するのか

Copy Fail は Linux カーネルのファイルコピー機能に関係している。現代の Linux には、copy_file_range、splice 系の経路、異なるファイルシステム間のデータコピー最適化など、複数の効率的なコピー経路がある。これらの仕組みは、ユーザー空間とカーネル空間の間のデータ移動を減らし、大きなファイルコピーの性能を高めるために用意されている。

問題は、高性能なコピー経路がページキャッシュ、ファイルオフセット、権限チェック、ファイルシステムコールバックを再利用することが多い点にある。どこかの境界条件の処理が厳密でない場合、カーネルが誤った権限コンテキストで書き込みを行ったり、本来攻撃者が変更できないデータページを制御できる形で露出したりする可能性がある。

Copy Fail の主なリスクは次のように整理できる。

攻撃者は root 権限を必要としない。
攻撃入口は一般的なファイルコピー機能にある。
影響点はカーネル空間にある。
コンテナ環境では、namespace やマウント隔離を迂回する可能性がある。
悪用に成功すると、コンテナが変更できないはずのホスト上の内容へ書き込める可能性がある。

これが Copy Fail が大きく取り上げられる理由である。コンテナセキュリティは Linux カーネルが提供する隔離機能に依存している。カーネル経路そのものに不正書き込みがあると、コンテナ境界は脆くなる。

なぜコンテナ環境でより敏感なのか

コンテナは仮想マシンではない。コンテナ内のプロセスとホストは同じ Linux カーネルを共有しており、namespace、cgroup、capability、seccomp、AppArmor/SELinux などの仕組みによって隔離されている。

脆弱性がユーザー空間サービスにある場合、通常は一つのコンテナや一つのプロセスに影響が限定される。しかし脆弱性がカーネルにあり、しかも非特権ユーザーからトリガーできる場合、攻撃者はコンテナ内部からホストへ影響を及ぼす可能性がある。

Copy Fail の危険性はここにある。多くのプラットフォームでは、ユーザーがビルドジョブを投入したり、スクリプトを実行したり、コンテナを起動したり、プラグインを動かしたりできる。攻撃者がコンテナ内でコードを実行できるだけで、カーネルのファイルコピー経路を利用して隔離を突破しようとする可能性がある。

高リスクな環境には次のようなものがある。

Kubernetes クラスター内の信頼できないワークロード。
CI/CD プラットフォームの共有 Runner。
ユーザーがコードをアップロードして実行できるサンドボックス。
マルチテナント Linux ホスト。
コンテナ化された PaaS。
サードパーティ製プラグインや拡張を実行するシステム。

これらの環境で影響を受けるカーネルが使われており、追加の制限が不足している場合、リスクは明らかに高まる。

影響範囲はカーネルのパッチ状態を見る必要がある

この種の脆弱性は、ディストリビューション名だけでは判断できない。同じ Ubuntu、Debian、RHEL、Fedora、Arch であっても、影響を受けるかどうかは実際に実行中のカーネルパッケージと、ディストリビューションが修正をバックポート済みかどうかに依存する。

調査では、まず次の三点を確認する。

現在実行中のカーネルバージョン。
ディストリビューションのセキュリティアドバイザリに CVE-2026-31431 が含まれているか。
クラウドベンダーやマネージドプラットフォームがホストカーネルを修正済みか。

まずシステム上でカーネルバージョンを確認する。

`1`	`uname -a`

そのうえで、ディストリビューションのセキュリティアドバイザリ、カーネル changelog、クラウドプラットフォームの告知を確認する。多くのエンタープライズディストリビューションは古いカーネルブランチへセキュリティ修正をバックポートするため、メジャーバージョンだけで安全かどうかを判断してはいけない。

一時的な緩和策

最も確実な修正はカーネル更新である。ただし、すぐにパッチを展開できない環境では、まず露出面を下げることができる。

一般的な緩和の方向性は次の通り。

信頼できないユーザーに特権コンテナを実行させない。
コンテナへ機密性の高いホストパスをマウントしない。
コンテナの capability を絞り、特に不要な CAP_SYS_ADMIN を付与しない。
seccomp、AppArmor、SELinux で危険なシステムコールとファイルアクセスを制限する。
信頼できないワークロードを、より隔離の強い仮想マシンへ移す。
CI/CD Runner はジョブごとに破棄し、同じホストを長期間使い回さない。
異常なファイル書き込み、権限変更、コンテナエスケープの兆候を監視する。

これらの対策はパッチの代替にはならない。目的は、パッチが本番環境に届くまでの間、悪用成功率と影響範囲を下げることである。

修正の優先順位

環境のリスクに応じて優先順位を付けるのがよい。

優先して修正すべきもの：

外部にコンテナ実行機能を提供するプラットフォーム。
信頼できないコードを実行する CI/CD ノード。
マルチテナント Kubernetes ノード。
ユーザー定義プラグインやスクリプト実行機能を持つシステム。
共有開発機、教育用マシン、実験環境。

相対的に優先度が低いもの：

単一ユーザーのデスクトップ。
信頼済みサービスだけを実行する内部ホスト。
信頼できないコードをすでに仮想マシンで隔離している環境。

リスクが低い場合でも、ディストリビューション経由でカーネルを更新することを推奨する。カーネル脆弱性はより複雑な攻撃チェーンに組み込まれることが多く、パッチを遅らせる利点はあまりない。

運用チーム向けチェックリスト

次の順序で対応できる。

すべての Linux ホストとコンテナノードを棚卸しする。
信頼できないコードを実行するマシンを特定する。
現在のカーネルバージョンとディストリビューションのセキュリティアドバイザリを確認する。
高リスクノードを優先して更新する。
すぐに更新できないノードには一時的な隔離ポリシーを適用する。
コンテナランタイム設定を確認し、不要な特権とホストマウントを削除する。
更新後にノードを再起動し、新しいカーネルが実際に有効になっていることを確認する。
後続の監査に備えて変更記録を残す。

カーネルパッケージをインストールしただけでは、システムが新しいカーネルで動いているとは限らない。更新後は必ず再起動し、再度確認する。

`1`	`uname -a`

まとめ

Copy Fail / CVE-2026-31431 の要点は、どこかのアプリケーションがクラッシュすることではなく、Linux カーネルのファイルコピー経路に権限境界の問題があることだ。非特権コードが、より高い権限のデータ書き込み経路へ触れる機会を持つため、コンテナ環境やマルチテナント環境では特に注意が必要である。

この種の脆弱性に対応するうえで重要なのは次の二点だ。

ディストリビューションまたはクラウドベンダーが提供するカーネルパッチをできるだけ早く適用する。
パッチ展開前は、信頼できないコード、特権コンテナ、機密性の高いホストマウントを制限する。

個人デスクトップでは、すぐに慌てる必要がある問題ではないかもしれない。しかし、コンテナプラットフォーム、CI/CD、サンドボックス、共有ホストを運用しているチームにとっては、高優先度のカーネルセキュリティ更新として扱うべきである。

参考ソース：

Linux Kernel 7.0 更新内容の整理

Fri, 01 May 2026 14:46:07 +0800

Linux カーネルのバージョン番号は、以前からセマンティックバージョニングではない。メジャーバージョンの上昇は、主にメンテナンス周期上のロールアップに近い。 Linus Torvalds もリリースメールで 7.0 を通常のリリースとして説明しており、最後の週はネットワーク、アーキテクチャ、ツール、セルフテスト、ドライバまわりの小さな修正が中心だった。

本当に注目すべきなのは、この増分更新の中身である。 Linux 7.0 は、ファイルシステム、メモリ管理、ハードウェアサポート、セキュリティ分離、Rust サポート、ドライバ整理など、複数の領域にまたがっている。

ファイルシステム：XFS、EXT4、NTFS3 に変更

Linux 7.0 で最も体感しやすい更新の一つはファイルシステムだ。

XFS には自己修復に関連する機能が入った。新しい汎用ファイルシステムエラー報告の仕組みと組み合わせることで、ファイルシステムは metadata の破損や I/O エラーを、より統一された方法でユーザー空間へ伝えられる。適切なシステムサービスと連携すれば、XFS はファイルシステムをマウントしたまま一部の修復処理を自動で扱える。すべてのディスク破損を無痛で直せるという意味ではないが、サーバーや長時間稼働するシステムでは、エラー検出から修復までの経路がより整う。

EXT4 は並行 direct I/O 書き込み性能を引き続き改善している。バックアップ、ビルド、ダウンロード、データベース、ログ処理などが同時にディスクへ書き込む環境では、こうした最適化により並行書き込み経路がより安定する。すべてのデスクトップユーザーがすぐ体感する変化ではないが、高 I/O の場面では意味がある。

NTFS3 も比較的大きなドライバ更新を受けている。内容には delayed allocation、iomap ベースのファイル操作、大きなディレクトリを走査する場面での readahead 改善が含まれる。 Linux から Windows パーティションや外付け NTFS ディスクをよく使う場合は、注目してよい更新だ。

さらに exFAT は複数 cluster の順次読み取りを改善しており、一部の小さな cluster のデバイスでは順次読み取りが速くなる。

メモリと swap：メモリ圧迫時の挙動を引き続き改善

Linux 7.0 は、ここ数バージョンで進んできた swap サブシステムの整理を継続している。今回の重点の一つは、swap からメモリへ読み戻す経路の改善だ。特に、複数のプロセスが同じスワップアウト済みページを共有している場合、スループットが向上する。

デスクトップユーザーにとっては、「急にシステムが速くなった」と感じる種類の変化ではないかもしれない。しかし、メモリが厳しい環境、コンテナが密集したホスト、永続化を有効にした Redis 系サービス、または zram とバックエンドディスクを組み合わせた構成では、メモリ圧迫時の揺れを減らす助けになる。

zram 関連の経路も最適化されている。以前は一部のケースで、カーネルが zram ページをいったん展開してからバックエンドデバイスへ書き込む必要があった。新しい経路では圧縮データを直接書き込めるため、不要な処理を減らせる。

CPU と性能：Intel TSX auto、スレッドとファイル操作の高速化

Linux 7.0 は Intel TSX のデフォルト方針を調整した。過去のセキュリティ問題により、多くのプロセッサでは TSX がデフォルトで無効化されていた。現在のカーネルはより細かい auto 方針を採用し、影響を受ける CPU では引き続き無効化し、影響を受けない、または有効化に適した CPU では自動的に有効化できる。

これは一部のマルチスレッドワークロード、特にトランザクショナル同期拡張に依存するアプリケーションに役立つ可能性がある。ただし、汎用的な高速化スイッチではない。実際の効果は CPU 型番とアプリケーションがその機能を使うかどうかに依存する。

また、Linux 7.0 には PID 割り当て、スレッドの作成/破棄、ファイルの open/close 経路の最適化も含まれる。これらは単独で大きく宣伝される機能ではないが、システム応答性や高並行サービスでの小さな改善として積み上がる。

ハードウェアサポート：新プラットフォームの準備と既存デバイスの改善

Linux 7.0 は大量のハードウェア有効化作業を継続している。この種の更新は、まだ広く出回っていない新プラットフォームへの準備と、すでにユーザーの手元にあるデバイスの改善に分けられる。

新プラットフォームでは、Linux 7.0 に Intel Nova Lake、Intel Crescent Island、AMD の新しいグラフィックス IP、AMD Zen 6 に関する準備がさらに含まれる。普通のユーザーにとってすぐ役立つとは限らないが、新しいハードウェアが登場した後に、より早くメインラインカーネルで対応できるかを左右する。

ARM64 とシングルボードコンピュータでは、Rockchip RK3588/RK3576 の H.264/H.265 ハードウェア動画デコードがメインラインサポートの範囲に入った。これは Orange Pi 5 や Radxa ROCK 5 などのデバイスが、ハードウェアデコード体験のためにベンダー BSP カーネルへ完全に依存しなくてよくなることを意味する。

ノートPCや周辺機器にも細かな更新が多い。

ASUS WMI は ROG、TUF 機種のバックライト、キーボードライト、ファンホットキー対応を改善。
HP WMI は一部 Victus 機種の手動ファン制御を追加し、音声インジケーターライトを修正。
Lenovo WMI は Legion デバイス向けにより多くの HWMON 監視情報を公開。
Intel Xe グラフィックスドライバはより多くの温度センサーを公開。
Intel Arc B シリーズのディスクリートGPUは、より深い PCIe 省電力状態へ入れる。
Rock Band 4 Bluetooth ギターと Logitech K980 Bluetooth キーボードのカーネルサポートが改善。

一つ一つは小さな変更だが、ノートPC、ゲームデバイス、開発ボード、周辺機器のユーザーにとっては、メインラインカーネルでの対応が進むほど、その後のディストリビューション保守が楽になる。

セキュリティと分離：io_uring で BPF フィルタリングが可能に

Linux 7.0 は io_uring に BPF フィルタリング機能を追加した。これはコンテナ、サンドボックス、高いセキュリティ要件を持つ環境で重要になる。

以前は攻撃面を減らすため、管理者が io_uring を丸ごと無効化することがあった。現在は BPF フィルタリングにより、許可する操作をより細かく制限できる。つまり、「全開」か「全停止」だけを選ぶ必要がなくなる。

これで io_uring のセキュリティリスクが自動的に消えるわけではない。しかし、システム管理者やランタイムフレームワークにとって、より制御しやすい分離手段が増える。

Rust サポートは単なる実験ラベルではなくなった

Linux 7.0 では、Rust for Linux の状態がさらに安定した。これはカーネルが大規模に Rust へ書き換えられるという意味ではなく、C が置き換えられるという意味でもない。

より正確には、カーネル内で Rust を使うための基盤が、より正式な段階に入ったということだ。今後、新しいドライバ、新しいサブシステム、または一部のセキュリティに敏感なコードでは、適した場面で Rust を選べる。これは段階的な道筋である。まずインターフェース、ビルド、ドキュメント、保守プロセスを安定させ、その後で具体的なコードを少しずつ増やしていく。

古い機能の整理：laptop_mode の削除

Linux 7.0 は laptop_mode を削除した。これは長い歴史を持つ省電力機能で、主に機械式ハードディスク時代のノートPCを対象に、ディスクのスピンアップを減らして電力を節約するものだった。

現在のノートPCは SSD が主流であり、カーネル内のメモリ回収、ブロックデバイス、ファイルシステム経路も大きく変化している。この古い仕組みを残し続けると保守コストが増え、テストカバレッジも理想的ではない。削除により、古いコードが現代的な経路へ与える影響を減らせる。

AI 関連キー：新世代のキーボード操作に向けた準備

Linux 7.0 は、コンテキスト AI 操作向けにいくつかの新しい HID keycode を追加した。たとえば、選択中の内容に対して操作を実行する、コンテキスト生成内容を挿入する、コンテキスト検索を開始するといった用途である。

これはカーネルに AI 機能が組み込まれたという意味ではない。将来のノートPCキーボードや周辺機器のために入力イベント定義を用意し、デスクトップ環境、アプリ、ベンダーツールがそれらのキーを認識できるようにするものに近い。実際に何ができるかは、ディストリビューション、デスクトップ環境、アプリケーション層の統合に依存する。

すぐにアップグレードすべきか

ローリングリリース系のディストリビューションを使っている場合、Linux 7.0 は通常のシステム更新として自然に入ってくる可能性が高い。 Ubuntu 26.04 LTS のような新しいディストリビューションでは、7.0 がデフォルトまたは主要なカーネルバージョンとして採用されることもある。

ただし、対象のマシンが本番環境、NAS、仮想化ホストである場合、またはクローズドソースドライバや独自カーネルモジュールに依存している場合は、バージョン番号が 7.0 になったという理由だけで手動アップグレードするのは勧めにくい。より安全な進め方は次の通り。

ディストリビューションが正式なカーネルパッケージを提供するのを待つ。
GPU、ネットワークカード、ZFS、VirtualBox、VMware、DKMS モジュールの互換性を確認する。
テスト機またはスナップショット環境で先に検証する。
7.0.x のポイントリリースでの修正状況を追う。

kernel.org の v7.x ディレクトリを見る限り、7.0.1、7.0.2、7.0.3 はすでに順次公開されている。手動でビルドまたはテストするなら、最初の 7.0 tarball だけを見るのではなく、最新の安定版 7.0.x を優先したほうがよい。

まとめ

Linux Kernel 7.0 は、「メジャーバージョンが上がったからすべてを書き換えた」リリースではない。むしろ、範囲の広い通常のカーネル更新に近い。ファイルシステムはより信頼性を増し、swap と I/O 経路は引き続き最適化され、新しいハードウェア対応は前進し、Rust、io_uring の分離、HID 入力定義も長期的な進化に必要な基盤を補っている。

一般的なデスクトップユーザーにとって、最も実用的な変化はハードウェアサポート、グラフィックスドライバ、省電力、ファイルシステム修復にあるかもしれない。サーバーや開発者にとっては、XFS のエラー報告、自己修復、io_uring BPF フィルタリング、swap 最適化、新プラットフォーム対応がより注目に値する。

参考ソース：