Linux カーネルのCIFS認証に19年間潜在していたローカル権限昇格が可能な脆弱性 CIFSwitch-30以上のディストリビューションに影響|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年06月03日更新日時: 2026年06月03日

2026年5月28日、セキュリティ研究者Asim Manizadaはoss-securityメーリングリストにて、Linuxカーネルとcifs-utils（ユーザー空間）の連携部分に存在するローカル権限昇格（LPE）脆弱性「CIFSwitch」を公開しました。

最大のリスクは、低権限の一般ユーザーアカウントさえあれば、信頼できる証明なしにroot権限のコードを実行できるという点です。脆弱なコードパスは2007年から存在しており、19年間にわたって誰にも気づかれないまま主要ディストリビューションに潜在していました。

公開されたPoC（概念実証コード）はGitHub上で誰でも入手可能であり、条件を満たす環境では一般ユーザーから確実にrootシェルを取得できます。CVEはまだアサインされていませんが、アップストリームのカーネルパッチ（コミット3da1fdf4efbc）はすでに公開済みで、各ディストリビューションへのバックポートが進んでいます。本記事では攻撃の仕組み・影響を受けるディストリビューションの全容・緩和策・情報システム担当者が取るべき対応を解説します。

サマリー

2026年5月28日、Asim Manizadaがoss-securityで「CIFSwitch」を公開。Linuxカーネルのcifs.spnego認証処理とcifs-utilsのcifs.upcallヘルパー間の信頼関係の欠如を悪用するローカル権限昇格
低権限の一般ユーザーが偽造したcifs.spnegokeyの記述を使って、rootとして実行されるcifs.upcallヘルパーを騙し、攻撃者制御のNSSモジュールをroot権限で実行させることでrootシェルを取得
脆弱なコードは2007年から存在する19年間の既存バグ。CVEは未アサイン（記事執筆時点）
デフォルト設定で即時悪用可能な環境：Linux Mint 21.3/22.3・CentOS Stream 9 GNOME・Rocky Linux 9 Workstation・Kali Linux（2021.4〜2026.1）・AlmaLinux 9.7・SLES 15 SP7
cifs-utilsインストールで悪用可能な環境：Ubuntu 18.04〜24.04・Debian 11/12/13・openSUSE Leap/Tumbleweed・Amazon Linux 2023等、全30以上のディストリビューション・エディション組み合わせ
アップストリームパッチ（コミット3da1fdf4efbc）は公開済み。即時回避策として、cifs.spnegoのrequest-keyルール上書きまたは非特権ユーザー名前空間の無効化が有効

1 脆弱性の概要—19年間誰も気づかなかったカーネルの設計上の欠落
2 攻撃チェーンの詳細—偽造キー記述からrootコード実行まで
3 影響を受けるディストリビューションの全容—30以上の組み合わせで確認
4 緩和策—カーネルパッチ・モジュール制御・request-keyルール上書き
5 最近のLinux LPE脆弱性の増加傾向
6 情報システム担当者が今すぐ確認すべき対応
7 FAQ
8 参考情報

脆弱性の概要—19年間誰も気づかなかったカーネルの設計上の欠落

oss-securityへの公開投稿（著者：Asim Manizada、2026年5月28日）によれば、CIFSwitchはLinuxカーネルとcifs-utils（ユーザー空間ツール群）の両方にまたがる脆弱性のチェーンです。

CIFS（Common Internet File System）はネットワーク越しにファイル共有へアクセスするためのプロトコルで、LinuxではSamba環境やWindowsファイルサーバーへの接続に広く使われています。CIFSマウントにKerberosによる認証が使われる場合、Linuxカーネルはユーザー空間に存在するヘルパープログラムcifs.upcallにその処理を委ねます。このヘルパーはrootとして実行され、kernel-CIFSが渡してきた情報（プロセスID・ユーザーID・認証情報キャッシュ・名前空間等）を信頼して動作します。

ここに根本的な設計上の欠落があります。

カーネルは、cifs.spnegoタイプのキーリクエストが本当にカーネルのCIFSクライアントから来ているのかを検証していませんでした。この欠落が2007年から2026年まで、19年間にわたって誰にも発見されずに残っていました。

Manizadaが2026年5月16日にカーネル/CIFSメンテナーへ報告し、linux-distrosメーリングリストでの事前通知（エンバーゴ）を経て、2026年5月28日にエンバーゴが解除されて公開に至りました。

攻撃チェーンの詳細—偽造キー記述からrootコード実行まで

攻撃の流れは以下のとおりです。

ステップ1：偽造キーリクエストの送信

低権限の一般ユーザーがrequest_key("cifs.spnego", ...)をkernel-CIFSからのリクエストに見せかけた偽造記述で呼び出します。記述にはpid（プロセスID）・uid（ユーザーID）・creduid（認証情報UID）・upcall_targetなどのフィールドが含まれており、攻撃者はこれらを任意の値に設定できます。

ステップ2：cifs.upcallのroot実行

リクエストを受け取ったカーネルは、デフォルトのrequest-keyルールに従ってcifs-utilsのcifs.upcallヘルパーをrootとして起動します。このヘルパーは「カーネルCIFSから来たはずのリクエスト」として、攻撃者が供給したフィールドの内容をそのまま信頼して処理を続けます。

ステップ3：名前空間の切り替えとNSSルックアップの悪用

upcall_target=appが設定されている場合、影響を受けるcifs-utilsのバージョンは、供給されたプロセスの名前空間に切り替えたうえで、権限を落とす前にNSS（Name Service Switch）ルックアップを実行します。

攻撃者は事前に、攻撃者が制御する/etc/nsswitch.confと悪意あるlibnss_*.so.2を含むプライベートマウント名前空間を用意しておきます。cifs.upcallがNSSルックアップでこの悪意あるNSSモジュールを読み込んだ時点で、攻撃者のコードがrootとして実行されます。

この攻撃に必要な前提条件は3つです。cifs-utilsがインストールされていること（デフォルトのcifs.spnegorequest-keyルールが存在すること）、CIFSカーネルモジュールがロード可能（またはカーネル組み込み）であること、そして非特権ユーザー/マウント名前空間が有効であることです。

なお、AppArmor・SELinuxのデフォルトポリシーが有効なディストリビューションでは、これらのポリシーが攻撃をブロックする場合があります。

影響を受けるディストリビューションの全容—30以上の組み合わせで確認

Manizadaのoss-security投稿に添付された影響評価表によれば、影響を受ける環境は2種類に分類されます。

デフォルト設定で即時悪用可能な環境（cifs-utilsが事前インストール・非特権名前空間がデフォルト有効・AppArmor/SELinuxポリシーが攻撃をブロックしない）：

Linux Mint Cinnamon 21.3および22.3、CentOS Stream 9 GNOME版、Rocky Linux 9 Workstation、Kali Linux（2021.4・2022.4・2023.4・2024.4・2025.4・2026.1のheadless版）、AlmaLinux 9.7 WorkstationおよびAzure クラウドイメージ、SLES 15 SP7・SAP 15 SP7・SAP 16。

cifs-utilsをインストールすれば悪用可能な環境（追加の設定変更は不要）：

Ubuntu 18.04・20.04・22.04（Desktop/Server）・24.04（Desktop minimal/full・Server）、Pop!_OS 22.04 Intel/24.04 Generic、Debian 11/12/13（netinst standard・GNOME/KDE/XFCE）、CentOS Stream 9（Cinnamon/KDE/MATE/XFCE版）、Rocky Linux 9（KDE/Workstation-Lite）・Rocky Linux 8 GenericCloud、openSUSE Leap 15.6（GNOME/KDE）・openSUSE Tumbleweed（GNOME/KDE）、Oracle Linux 8/9 KVM、Amazon Linux 2023 KVM。

つまり、エンタープライズ環境で広く使われるRHEL系（CentOS/Rocky/AlmaLinux）・Debian系（Ubuntu/Debian）・SUSE系のほぼ全バージョンが潜在的な影響を受けることになります。

緩和策—カーネルパッチ・モジュール制御・request-keyルール上書き

最優先：カーネルパッチの適用

アップストリームのカーネル修正コミット3da1fdf4efbc（”smb: client: reject userspace cifs.spnego descriptions”）がすでに公開されており、各ディストリビューションへのバックポートが進んでいます。

TuxCareによれば、Red Hat・Ubuntu・Debian・SUSE・Oracle・Amazonのダウンストリームへの配布が開始されています。各システムのパッケージマネージャー経由で最新のカーネルアップデートを適用してください。

即時適用可能な回避策①：cifs.spnegoのrequest-keyルールを上書きする

Kerberos認証を必要とするCIFS共有を使用していない場合、以下のコマンドでデフォルトのcifs.spnegoルールを無害なnegateルールに置き換えることで攻撃経路を排除できます：

cat >/etc/request-key.d/cifs.spnego.conf <<'EOF'
create cifs.spnego * * /usr/sbin/keyctl negate %k 30 %S
EOF

注意：ご利用の環境でkeyctlのパスが異なる場合は、which keyctlで確認のうえ適宜修正してください。

即時適用可能な回避策②：CIFSモジュールのブロック・cifs-utilsのアンインストール

CIFS/SMBネットワーク共有を使用していない環境であれば、CIFSカーネルモジュールのロードを禁止するか、cifs-utilsをアンインストールすることで根本的に攻撃面を排除できます。

即時適用可能な回避策③：非特権ユーザー名前空間の無効化

非特権ユーザー名前空間を無効化することでも攻撃チェーンを断ち切ることができます。ただし、この設定はコンテナ技術（Podman・Dockerのrootlessモード等）やその他ユーザー名前空間に依存するアプリケーションに影響する場合があります。無効化前にシステム全体への影響を確認してください。

最近のLinux LPE脆弱性の増加傾向

CIFSwitchは2026年に公開された一連のLinuxローカル権限昇格脆弱性の最新事例です。BleepingComputerの報道によれば、直近ではCopy Fail（CVE-2026-31431）・Dirty Frag・Fragnesia・DirtyDecrypt・PinTheftという複数のLPE脆弱性が次々と公開されており、Linuxカーネルの権限制御に関わるコードが集中的な研究対象となっています。

CIFSwitchが特に注目される点は、脆弱なコードが2007年から存在するという19年間の潜在期間の長さと、公開PoCによって攻撃の再現性が高い点です。PoCはGitHub（https://github.com/manizada/CIFSwitch）で誰でも入手可能であり、攻撃の参入障壁が低下しています。

情報システム担当者が今すぐ確認すべき対応

まず影響するシステムのインベントリ確認を実施してください。管理するLinuxサーバー・仮想マシン・コンテナホストにcifs-utilsがインストールされているかを確認します。rpm -q cifs-utils（RHEL系）またはdpkg -l cifs-utils（Debian系）で確認できます。

次にディストリビューションのアップデート情報を確認してください。各ベンダーのセキュリティアドバイザリページ（Red Hat Security Advisory・Ubuntu Security Notices・Debian Security Trackerなど）でカーネルパッチのリリース状況を確認し、適用可能になった時点で速やかにアップデートを実施してください。

パッチ適用までの間は上記の回避策のいずれかを適用してください。CIFS/Kerberos認証を使用していない環境であれば、request-keyルールの上書きが最も影響範囲が小さく推奨される緩和策です。

クラウド環境（Amazon Linux 2023・Oracle Linux on KVM等）を運用している場合、クラウドベンダー提供のマネージドカーネルアップデート機能（AWS Systems Manager Patch Manager等）を使った計画的なパッチ適用も検討してください。

FAQ

Q. CIFSを使っていないサーバーでも影響を受けますか？ A. cifs-utilsがインストールされていなければ、この攻撃は機能しません。ただし、yum groupinstallやapt installでメタパッケージをインストールした際にcifs-utilsが依存関係として含まれている場合があります。rpm -q cifs-utilsまたはdpkg -l cifs-utilsで確認してください。

Q. CVEがまだアサインされていないのはなぜですか？ A. CVEのアサインには手続きが必要で、脆弱性の公開・報告から実際にCVE番号が付与されるまで数日〜数週間かかることがあります。CVEがない状態でも、アップストリームのカーネルパッチは確認・適用できます。CVEアサイン後はkcarectl --patch-info | grep CVE-2026-（KernelCare環境）などで確認できます。

Q. AppArmor・SELinuxが有効であれば安全ですか？ A. oss-securityの開示によれば、一部のデフォルトAppArmor・SELinuxプロファイルはこの攻撃をブロックします。ただし、ポリシーの設定内容によっては防御されない場合もあります。セキュリティポリシーに依存するだけでなく、カーネルパッチの適用を推奨します。

Q. コンテナ環境（Docker・Kubernetes）でも影響を受けますか？ A. コンテナホスト（ノード）のLinuxカーネルが脆弱であり、コンテナ内からcifs.spnegoリクエストを発行できる場合は影響を受ける可能性があります。Kubernetes環境では、ホストのカーネルパッチ適用と並行して、非特権ユーザー名前空間へのアクセス制御を見直すことを推奨します。

Q. 悪用されたかどうかを確認する方法はありますか？ A. request_key(“cifs.spnego”, …)の異常な呼び出しを検出するには、カーネルの監査ログ（auditd）でシステムコールrequest_keyの監査ルールを設定することが有効です。また、予期しない新規プロセスのrootによる起動や、/etc/request-key.d/ディレクトリへの不審な変更も侵害の痕跡となります。