CVE-2026-64600 RefluXFS｜XFS reflink 環境の影響判定と対処の手順

はじめに

2026 年 7 月 22 日、Qualys Threat Research Unit から Linux カーネルの XFS ファイルシステムに関する脆弱性 CVE-2026-64600 が公表されました。RefluXFS と名付けられたこの脆弱性は、一般権限のローカルユーザーが、読み取り権限しか持たないファイルの内容をディスク上で書き換えられるというものです。実証コードでは root 権限の奪取までが確認されています。

RHEL 系のディストリビューションでは XFS がルートファイルシステムの既定であり、デフォルトインストールのままで条件が成立します。共有ホスティングやマルチテナント構成、CI ランナーのように、権限の低い利用者やジョブがローカルでコードを実行できる環境では、影響の確認を優先度高く進める必要があります。

結論として、影響を受けるのは「パッチ未適用のカーネル v4.11 以降」「reflink=1 の XFS ファイルシステム」「攻撃対象となるファイルと一般ユーザーが書き込めるディレクトリが同一ファイルシステム上に存在する」の 3 条件をすべて満たす環境です。reflink はファイルシステム作成時に決まる機能であり、後から無効化できないため、設定変更による緩和は基本的に効きません。恒久的な対処はベンダー提供の修正済みカーネルへの更新と再起動になります。

なお、本稿の執筆時点で実環境における悪用の報告は確認できていません。ただし実証コードの完成度が高く、初期侵入後の権限昇格として使われる可能性を前提に対応を検討することをおすすめします。

CVE-2026-64600（RefluXFS）の概要と深刻度

RefluXFS は、XFS のコピーオンライト処理における競合状態です。ファイルのアクセス権限の判定そのものは正しく行われており、その下層にあるブロックの管理で取り違えが起きる、という構造になっています。

書き込みが元のファイルへ「逆流」する

XFS の reflink は、ファイルの複製時にデータをコピーせず、双方のファイルが同じ物理ブロックを参照する状態を作る機能です。どちらかに書き込みが発生した時点で、書き込む側に新しいブロックを割り当てて内容を分岐させます。この分岐処理の途中に、書き込み先の判定が古い情報のまま残る余地がありました。

参考: RefluXFS: Local Privilege Escalation via XFS reflink direct-I/O race（Qualys Security Advisory）
“the write refluxes — flows backward — from the attacker’s own copy into the original file”
（書き込みが、攻撃者自身の複製から元のファイルへと逆流する）
https://cdn2.qualys.com/advisory/2026/07/22/RefluXFS.txt

攻撃者は、/etc/passwd や /usr/bin/su のような SUID-root バイナリを自分が所有する作業用ファイルへ reflink クローンし、その作業用ファイルに対して並行した書き込みを競わせます。条件が揃うと、片方の書き込みが攻撃者自身の領域ではなく、元のファイルを支えている物理ブロックへ着弾します。

重要なのは、書き込みがファイルの inode を経由しない点です。変更はディスク上に直接行われるため再起動後も残り、カーネルログには何も出力されず、対象ファイルの所有者・パーミッション・タイムスタンプ・サイズはいずれも変化しません。SUID-root バイナリを書き換えた場合、SUID ビットもそのまま維持されます。

FICLONE は複製元に読み取り権限、複製先に書き込み権限があれば実行できます。したがって、モード 0644 の /etc/passwd やモード 04755 の /usr/bin/su は、一般ユーザーでも複製の対象にできます。この操作自体は不具合ではなく、その後の処理に問題がありました。

CVSS v3.1 は 7.8、CWE-362

Red Hat が付与した CVSS v3.1 のベクターは CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H で、スコアは 7.8 に相当します。脆弱性タイプは CWE-362（共有リソースを用いた並行実行時の不適切な同期、いわゆる競合状態）に分類されています。

攻撃元がローカルに限られるため、単体では最高位の深刻度にはなりません。ただし、Web アプリケーションの脆弱性や資格情報の流出によってローカルでのコード実行を得た攻撃者にとって、この脆弱性はホスト全体の掌握へ進むための第 2 段階になります。アプリケーション層の侵入とローカル権限昇格が連鎖する構図として捉えると、優先度の判断がしやすくなります。 アプリケーション層側の直近の事例としては、関連記事『CVE-2026-66066 Rails の脆弱性｜libvips 8.13 要件と鍵の再発行手順』で扱った Active Storage の任意ファイル読み取りが挙げられます。

発見の経緯

Qualys のアドバイザリ冒頭には、この脆弱性が発見された経緯が記載されています。Anthropic から Claude Mythos Preview の提供を受け、Dirty COW に類似した脆弱性を Linux カーネルから探索させる実験を行ったところ、対象を競合状態、次に mm/ と fs/ ディレクトリ、最後に各ファイルシステムのディレクトリへと段階的に絞り込む過程で、モデルが XFS の競合状態を発見し、root 権限奪取に至る実証コードを作成したとのことです。Qualys 側がそれをレビューし、Fedora Server 44 のデフォルトインストール環境で再現を確認しています。

防御側の観点では、既存のコードベースに長く潜在していた競合状態が、こうした手法で今後も掘り起こされる可能性を前提に置く必要があります。AI モデルのサイバー能力とそれに対する安全策の議論は、関連記事『Claude Fable 5 のサイバーセキュリティ安全策』でも取り上げています。

影響を受ける 3 条件と自環境の判定手順

Qualys のアドバイザリは、影響を受ける条件を 3 つに整理しています。この 3 つをすべて満たす場合に限り影響を受ける、という書き方になっています。

条件 1: パッチ未適用のカーネル v4.11 以降

この脆弱性は 2017 年 2 月、Linux 4.11 のコミット 3c68d44a2b49（xfs: allocate direct I/O COW blocks in iomap_begin）によって混入したとされており、それ以降のすべてのメインラインおよび安定版カーネルに存在します。修正は 2026 年 7 月 16 日にコミット 2f4acd0（xfs: resample the data fork mapping after cycling ILOCK）としてカーネルのソースツリーへマージされました。

現在サポートされているカーネルは事実上すべて該当するため、この条件は「修正が適用済みかどうか」の確認に読み替えることになります。

# 稼働中のカーネルバージョン確認
uname -r

条件 2: reflink が有効な XFS ファイルシステム

判定の実質的な分かれ目はこの条件です。

# ルートファイルシステムの確認
xfs_info / | grep reflink=

出力に reflink=1 が含まれていれば該当します。reflink=0 の場合、またはルートファイルシステムが XFS ではなく xfs_info が失敗する場合、ルートファイルシステム経由では該当しません。その場合も、他にマウントされている XFS があれば同じ確認を行う流れになります。

マウント済みの XFS をまとめて確認する場合は、findmnt と組み合わせると 1 コマンドで済みます。

for m in $(findmnt -nt xfs -o TARGET); do
  echo "$m $(xfs_info "$m" 2>/dev/null | grep -o 'reflink=[01]')"
done

reflink は xfsprogs 5.1.0（2019 年 7 月）以降、mkfs.xfs の既定値となっています。Red Hat はこれに先行して、RHEL 8.0 GA（2019 年 5 月）向けに xfsprogs 4.17.0-2.el8 へ既定値を取り込んでいます。

そしてこの機能はスーパーブロックに記録され、ファイルシステム作成時に確定します。後からマウントオプションや sysctl で無効化する手段はありません。無効化するには作り直しが必要になるため、設定変更による緩和という選択肢は事実上存在しません。

条件 3: 攻撃対象と書き込み可能ディレクトリの同居

3 つ目は、同一の XFS ファイルシステム上に、攻撃価値のあるファイル（root 所有の設定ファイルや SUID-root バイナリ）と、一般ユーザーが書き込めるディレクトリの両方が存在することです。

アドバイザリは、この条件が単一ボリューム構成のデフォルトインストールでは常に成立すると述べています。/var/tmp は誰でも書き込み可能で、/etc や /usr/bin と同じルートファイルシステム上に置かれているためです。

つまり、条件 2 を満たす一般的な構成では、条件 3 は自動的に成立していると考えたほうが実態に合います。

ディストリビューション別の該当有無

既定のインストーラーが reflink=1 の XFS をルートファイルシステムとして作成し、初期状態で条件を満たすディストリビューションは次のとおりです。

Debian、Ubuntu、Fedora Workstation、SLES、openSUSE、Arch は、既定のインストーラーがルートファイルシステムに XFS を使用しないため、初期構成では該当しません。ただし、インストール時に管理者が XFS を選択し、同梱されていた xfsprogs が reflink を既定で有効にするバージョンであった場合は該当します。

運用上の分岐として押さえておきたいのが RHEL 7 系の扱いです。 RHEL / CentOS 7 は、カーネル 3.10 が XFS の reflink 自体に対応しておらず、同梱の xfsprogs 4.5.0 には -m reflink オプションも存在しないため、いかなる構成でも該当しません。同じ理由から、スーパーブロックをそのまま引き継ぐ Leapp による RHEL 7 から 8 へのインプレースアップグレードも該当せず、RHEL 8 以降を新規インストールした環境のみが対象となります。

長期運用のサーバー群では、新規構築と移行構築が混在していることが少なくありません。ディストリビューションのバージョンだけで一律に判断せず、xfs_info の出力で確定させる進め方をおすすめします。

攻撃が成立する仕組みと検知が困難な理由

この脆弱性は、権限判定の誤りではなく、ロックを一時的に手放している間に前提が古くなることに起因します。防御側が影響範囲を判断できる範囲で、構造を整理します。

ロックの解放中に判断材料が古くなる

XFS は、reflink で共有されたブロックへの書き込みを受け取ると、まず「そのブロックはまだ共有されているか」を判定します。共有されていればコピーオンライトで新しいブロックを割り当て、共有されていなければその場で書き込みます。

判定に必要なトランザクションの確保は、ログ領域の空きを待つ場合があります。ロックを保持したまま待つとデッドロックの恐れがあるため、いったんロックを解放し、トランザクションを確保してから再取得する実装になっていました。問題は、再取得した後の再確認にあります。

参考: xfs: resample the data fork mapping after cycling ILOCK（Linux カーネル修正コミット）
“the directio write proceeds with a stale data fork mapping”
（ダイレクト I/O 書き込みが、古くなったデータフォークのマッピングのまま進行する）
https://git.kernel.org/stable/c/2f4acd0fcd862e22eab45690ec2c08c80b6ef2e7

修正コミットの説明によれば、xfs_reflink_fill_cow_hole および xfs_reflink_fill_delalloc は ILOCK を解放して再取得するため、渡されていたマッピングは再取得の時点で古くなります。従来の実装は CoW フォークのマッピングを再取得する一方で、データフォークのマッピングは更新していませんでした。その結果、参照カウント用の btree に対して誤った物理ブロックを問い合わせ、共有状態の判定値が不正確になります。

判定が「共有されていない」に転んだ場合、古いマッピングのままダイレクト I/O の書き込みが進みます。修正では、ILOCK の解放と再取得の前後でシーケンスカウンターが変化した場合に、データフォークのマッピングを取得し直すようになりました。

要点は、書き込み先の物理ブロックが、判定時点と実際の書き込み時点で別のファイルのものに入れ替わりうる、という点です。 一方のファイルが先にコピーオンライトを完了して別のブロックへ移った結果、残された古いブロックの所有者が複製元のファイルだけになり、そこへ書き込みが着弾します。

痕跡が残りにくい理由

運用面で押さえておきたいのは、この書き込みが通常のファイル書き込み経路を通らない点です。

Qualys のアドバイザリによれば、変更はディスク上に直接行われ、カーネルログには何も出力されず、対象ファイルの inode には触れません。そのため、モード・所有者・更新日時・サイズはいずれも変化せず、SUID-root バイナリであれば SUID ビットも保持されます。変更は再起動後も残ります。

加えて、書き込みは複製側のアドレス空間を通って行われるため、対象ファイルのページキャッシュは無効化されません。攻撃者側が明示的にキャッシュを破棄するまで、書き換えは通常の読み取りや実行には反映されない、という挙動になります。

この性質により、更新日時やパーミッションの変化を監視するタイプのファイル整合性監視では、書き換えを検知できません。 検知の考え方については後述のセクションで扱います。

カーネル更新と暫定緩和策

恒久的な対処は、修正が取り込まれたカーネルへの更新と再起動です。順に整理します。

修正が取り込まれたバージョン

アップストリームの安定版では、5.15.212、6.1.178、6.6.145、6.12.96、6.18.39、7.1.4 以降に修正が含まれています。

Red Hat のエラータは 2026 年 7 月 14 日から 17 日にかけて公開されており、主なものは次のとおりです。

EUS や E4S、AUS といった延長サポート系のチャネルにも個別のエラータが用意されています。運用中のチャネルに合わせて確認することをおすすめします。

なお、Red Hat の情報では RHEL 9 の kernel-rt など、公開時点で修正が提供されていないパッケージも一部残っています。リアルタイムカーネルを使用している場合は、対象パッケージの状況を個別に確認してください。

更新と適用確認

# カーネルの更新
sudo dnf update kernel

# 再起動後、稼働カーネルを確認
uname -r

# インストール済みカーネルの changelog で修正の取り込みを確認
rpm -q --changelog kernel | grep -i CVE-2026-64600

更新しただけでは有効になりません。 稼働中のカーネルが差し替わるのは再起動後であるため、uname -r の出力が修正済みバージョンになっているかを確認する工程を、作業手順に含めておくと確実です。ライブパッチの適用可否は製品とサブスクリプションによって異なるため、利用している場合はベンダーの提供状況を確認する流れになります。

Red Hat が示す暫定緩和策

再起動の調整に時間がかかる環境向けに、Red Hat は SystemTap を用いた緩和策を提示しています。

参考: CVE-2026-64600（Red Hat Customer Portal）
“Exploitation requires local access and read permission to the target file.”
（悪用には、ローカルアクセスと対象ファイルへの読み取り権限が必要です）
https://access.redhat.com/security/cve/cve-2026-64600

この緩和策は、SystemTap を guru モードで実行し、XFS の xfs_file_remap_range を対象としたスクリプトを読み込むものです。適用中は、FICLONE ioctl やその派生、および copy_file_range() システムコールを呼び出したアプリケーションが -EOPNOTSUPP（-95）を受け取るようになります。つまり、reflink の利用そのものを止めることで条件を崩す考え方です。

適用にあたっては、Red Hat が挙げている 3 つの注意点を踏まえる必要があります。

1. SystemTap のスクリプトはカーネルモジュールとしてコンパイルされる

Secure Boot が有効な環境ではカーネルがロックダウン状態にあり、有効な Secure Boot 鍵または MOK に登録された鍵で署名されたモジュールしか読み込めません。SystemTap 側で署名は可能ですが、鍵の管理は利用者側の責任範囲となります

2. モジュールは再起動をまたいで維持されない

マシンの再起動や stap プロセスの終了によって解除されるため、その都度の再適用が必要です

3. CoW や reflink に依存し、代替手段を持たないプログラムは失敗する可能性がある

cp --reflink=always はその一例で、Red Hat Enterprise Linux の既定である --reflink=auto への変更が案内されています

バックアップやコンテナイメージの管理で reflink を前提にしている環境では、この副作用が業務影響につながる可能性があります。 適用前に、reflink を利用している処理の洗い出しを行っておくと判断しやすくなります。

設定変更による緩和が効かない理由

reflink はスーパーブロックに記録される機能であり、マウントオプションや sysctl で後から無効化する手段がありません。無効化するにはファイルシステムの作り直しが必要になるため、既存環境で実施できる現実的な選択肢とは言えません。

影響条件のうち 3 つ目、すなわち攻撃対象と書き込み可能ディレクトリの同居については、/var/tmp や /home を別のファイルシステムへ分離することで理論上は崩せます。ただし、これは Qualys や Red Hat が緩和策として案内しているものではなく、既存環境での実施コストも小さくありません。新規構築時のパーティション設計における選択肢として捉えるのが妥当です。

悪用の痕跡を確認する観点

すでに悪用されていないかを確認したい場合、通常の侵害調査とは前提が異なります。この脆弱性は、監視の主要な手がかりをほとんど残さないためです。

メタデータ監視型の整合性チェックが空振りする理由

参考: Linux kernel local privilege escalation in XFS (“RefluXFS”)（University of Toronto Information Security）
“File integrity monitoring keyed on metadata alone will report clean on a compromised file.”
（メタデータのみを見るファイル整合性監視は、改ざんされたファイルを正常と報告します）
https://security.utoronto.ca/advisories/linux-kernel-local-privilege-escalation-in-xfs-refluxfs/

書き換えはブロック層で行われ、inode には触れません。所有者、パーミッション、更新日時、サイズ、SUID ビットのいずれも変化しないため、これらの属性の変化を検知条件にしている監視は、改ざんされたファイルに対しても「変更なし」と報告します。カーネルログにも出力がないため、ログ収集基盤側で拾える事象もありません。

したがって、確認の軸は内容そのものの照合になります。ハッシュ値または本文の比較でなければ、書き換えを捉えることはできません。

パッケージ由来ファイルの照合

RPM 系のディストリビューションであれば、パッケージが管理しているファイルについては、インストール時のダイジェストと現在の内容を比較できます。SUID-root バイナリの多くはこの対象に含まれます。

# インストール済み全パッケージのファイルを検証
sudo rpm -Va

# ダイジェストの不一致のみを抽出
sudo rpm -Va | grep -E '^\S*5'

出力の 3 文字目に 5 が現れる行が、ダイジェストの不一致を示します。設定ファイルは運用の中で変更されるのが通常のため、c の印が付く行は切り分けが必要です。着目したいのは、本来変更されないはずのバイナリ、特に SUID が付与されたファイルです。

# SUID-root バイナリの一覧
sudo find / -xdev -perm -4000 -type f 2>/dev/null

この一覧に含まれるファイルについて、rpm -Vf で個別に照合していくと、確認範囲を絞り込めます。

なお、この照合には前提があります。RPM のデータベース自体もローカルのファイルであるため、root 権限を得た攻撃者による改変の可能性を排除しきれるわけではありません。厳密な確認を行う場合は、別環境で取得した信頼できるパッケージのダイジェストと突き合わせる手順が望ましいという点は押さえておく必要があります。

認証情報ファイルの確認

/etc/passwd はパッケージ管理下にありながら設定ファイルとして扱われるため、ダイジェストの照合だけでは判断できません。内容の観点で確認する形になります。

# パスワードフィールドが空のアカウントを抽出
awk -F: '($2 == "") {print $1}' /etc/passwd

# root アカウントのパスワード状態を確認
sudo passwd -S root

Qualys の実証コードは、/etc/passwd の root 行からパスワードフィールドの x を取り除き、後続のバイト位置を保ったまま書き換える方式を採っていました。ファイルサイズが変わらない点が、この手法の特徴です。そのため、サイズや行数だけを見る確認では見落とす可能性があります。

あわせて、/etc/shadow や /etc/sudoers、/root/.ssh/authorized_keys といった権限に関わるファイルについても、内容の妥当性を確認しておくと範囲を押さえられます。

確認結果の扱い

痕跡が見つからなかったことは、悪用されていない証明にはなりません。もともとログが残らない性質の脆弱性であるため、確認できる範囲には限界があります。

そのうえで実務的には、次のように切り分けると判断しやすくなります。

• 該当条件を満たしていた期間（脆弱なカーネルが稼働していた期間）
• その期間に、一般権限でのローカルコード実行が可能だった主体の有無
• 内容照合で検出された不一致の有無

共有ホスティングやマルチテナント構成のように、信頼できない利用者がローカルでコードを実行できた環境では、確認範囲を広げる判断が妥当です。 逆に、ローカルアカウントが管理者のみで、外部からのコード実行経路もなかった環境であれば、優先度を下げる根拠になります。

まとめ

CVE-2026-64600（RefluXFS）は、XFS のコピーオンライト処理における競合状態に起因する権限昇格の脆弱性です。読み取り権限しか持たないファイルの内容をディスク上で書き換えられるため、一般権限のローカルユーザーが root 権限を取得できる可能性があります。reflink はファイルシステム作成時に決まる機能で後から無効化できないため、対処は修正済みカーネルへの更新と再起動が基本となります。

• XFS の reflink 有効環境に影響する CVSS v3.1 7.8 の権限昇格の脆弱性
• 影響条件はカーネル v4.11 以降、reflink=1、書き込み可能ディレクトリの同居
• RHEL 8 以降および Fedora Server、Amazon Linux はデフォルト構成で該当
• 判定は xfs_info の出力に reflink=1 が含まれるかで確定
• 恒久策は修正済みカーネルへの更新と再起動後の稼働バージョン確認
• 暫定緩和は SystemTap による reflink の抑止だが再起動で解除
• メタデータ監視型の整合性チェックでは書き換えを検知できず内容照合が必要

以上、最後までお読みいただきありがとうございました。