CIFSwitch（19年物のcifs.spnego特権昇格）でrootを取られる｜影響ディストロと緩和手順

「ファイルサーバーをマウントするためにcifs-utilsを入れただけ」

そのサーバーで、一般ユーザーのアカウントを1つ取られたら、root を取られる。19年前から仕込まれていた、と聞かされて、自分の管理してきたファイルサーバー群を頭の中で点検し始めました。

2026年5月下旬、Linux カーネルの CIFS サブシステムに潜む特権昇格の脆弱性「CIFSwitch」が、発見者 Asim Manizada 氏のブログと oss-security メーリングリストで公開されました。PoC（実証コード）も同時に出ています。非特権の一般ユーザーが、条件のそろった環境で root を取れる。しかも CentOS Stream 9、Rocky Linux 9、AlmaLinux 9、Kali、SLES など、既定構成のまま踏める環境が複数報告されています。

本稿では、現役のサーバー管理者の視点で「自分の環境は脆弱なのか」を切り分け、root を取られる前に今週中に何を確認・実行すべきかを書きます。CVE番号はまだ採番されていない（申請中）ため、本文ではCVE番号を断定しません。

CIFSwitch とは何か（3行で）

要点だけ先に書きます。

・Linux カーネルの cifs.spnego という鍵タイプに、鍵の説明文（description）を検証する仕組みがなかった
・root 権限で動くヘルパ cifs.upcall が、その説明文を「カーネルが作ったもの」と信じ込んでしまう
・非特権ユーザーが説明文を偽装し、root のまま攻撃者の名前空間に切り替えさせ、悪意あるライブラリを読み込ませて root でコードを実行する

公式情報の整理は以下のとおりです。

・名称: CIFSwitch（cifs.spnego ローカル特権昇格）
・発見者: Asim Manizada 氏（本人ブログ heyitsas.im が一次情報）
・種別: ローカル特権昇格（非特権ユーザー → root）
・CVE番号: 公開時点で未採番（申請中）
・公開時期: 2026年5月下旬。PoC は GitHub（manizada/CIFSwitch）で公開済み
・潜在期間: 2007年から。約19年間、カーネルに残っていた
・上流カーネル修正コミット: 3da1fdf4efbc490041eb4f836bf596201203f8f2

ここで強調しておきたいのは、これは「リモートから誰でも踏める」種類の脆弱性ではない、という点です。攻撃者はまず、そのサーバー上で一般ユーザー権限を持っている必要があります。SSH の総当たり突破、Web アプリ経由の侵入、委託作業者の端末経由。入口は何でもあり得ますが、「足がかりを1つ取られた後、root まで一気に駆け上がる」局面で効いてくる脆弱性です。多段防御の最後の砦が抜ける、と考えるとわかりやすいです。

なぜ cifs.spnego の偽装で root が取れるのか

ここは技術的な話です。読まなくても運用は回せますが、攻撃の流れを把握しておくと、緩和策のどれが効くのかを自分で判断できます。

CIFS で Kerberos 認証を使うとき、カーネルは認証情報をユーザー空間のヘルパに取りに行かせます。この「カーネルからユーザー空間への呼び出し」が upcall で、その担当が cifs.upcall というプログラムです。root 権限で動きます。

カーネルは upcall のとき、request_key の仕組みを使って cifs.spnego という鍵タイプのリクエストを発行します。問題は、この cifs.spnego 鍵タイプに「説明文が本当にカーネル由来か」を検証する .vet_description が実装されていなかったことです。結果として、非特権プロセスが request_key() を直接叩いて、説明文（pid・uid・creduid・upcall_target などのフィールド）を自由に偽装できました。

攻撃の流れはこうなります。

・攻撃者が upcall_target=app と、自分が制御するプロセスの pid を埋め込んだ説明文を偽装する
・cifs.upcall（root）は、その説明文を信じ、指定された pid の名前空間に setns(2) で切り替える
・特権を落とす前に getpwuid() でアカウント情報を引く。このとき名前解決に NSS（Name Service Switch）が走る
・攻撃者の mount 名前空間には、細工した /etc/nsswitch.conf と悪意ある libnss_*.so.2 が仕込んである
・root のまま、その悪意あるライブラリが読み込まれ、攻撃者のコードが root 権限で実行される

「鍵の説明文を信じてしまう」「特権を落とす前に名前解決する」「名前解決のライブラリを差し替えられる」。この3つが重なって成立する連鎖です。設計の隙間を丁寧につないだ攻撃で、発見者は AI を使った半自動の解析手法で見つけた、と説明しています。眠っていた古いコードの欠陥が掘り起こされる流れは、ここ最近のカーネル脆弱性に共通しています。

自分の環境は脆弱か——3つの条件を切り分ける

CIFSwitch が成立するには、次の3条件がすべてそろう必要があります。逆に言えば、1つでも崩せば踏まれません。落ち着いて自分の環境を切り分けてください。

・条件1: パッチ未適用の脆弱なカーネルである
・条件2: cifs-utils がインストールされていて、対象バージョン（6.14 以上が主。一部の古いビルドもバックポートで影響）である
・条件3: 非特権ユーザー名前空間（unprivileged user namespaces）の作成が許可されている

確認コマンドは以下です。

cifs-utils が入っているか、バージョンは何か。

・RHEL系: rpm -q cifs-utils
・Debian系: dpkg -l cifs-utils

cifs モジュールが読み込まれているか。

・lsmod | grep cifs

非特権ユーザー名前空間が許可されているか。

・cat /proc/sys/user/max_user_namespaces（0なら作成不可）
・Debian系では sysctl kernel.unprivileged_userns_clone（0なら無効）

発見者が「既定構成のまま踏める」と報告したディストロは、Linux Mint 21.3/22.3、CentOS Stream 9、Rocky Linux 9、AlmaLinux 9、Kali Linux 2021.4～2026.1、SLES 15 SP7・SLES SAP 15 SP7・SLES SAP 16 です。Ubuntu・Debian・openSUSE・Oracle Linux・Amazon Linux なども、cifs-utils を入れていれば条件次第で対象になり得ます。

私の感覚では、ファイルサーバーやバックアップ用途で Windows 共有を mount している中規模以下の現場は、ほぼ確実に cifs-utils が入っています。「CIFS なんて使っていない」と思い込んでいたサーバーで、過去の検証の名残りでパッケージだけ残っている、というケースもよくあります。まず棚卸しから始めてください。

root を取られる前に——今週中の緩和策

パッチ提供状況は配布版ごとに異なり、本稿執筆時点で全ディストロの提供状況を網羅的に確定できません。カーネル更新が降りてくるのを待つ間も含め、発見者が推奨する緩和策のいずれかを今すぐ打ってください。Kerberos 認証付き CIFS を使っていない現場なら、緩和のハードルはかなり低いです。

緩和策1: cifs モジュールをブロックする（CIFS/SMB マウントが不要な場合）。

・/etc/modprobe.d/ に blacklist cifs を記述し、再起動後に lsmod | grep cifs で消えていることを確認する

緩和策2: cifs-utils を削除する（Kerberos CIFS 認証が不要な場合）。

・RHEL系: dnf remove cifs-utils
・Debian系: apt remove cifs-utils

緩和策3: request-key ルールを上書きして cifs.spnego の upcall を無効化する（Kerberos 認証が不要な場合）。発見者が提示している設定は次のとおりです。

・/etc/request-key.d/cifs.spnego.conf に create cifs.spnego * * /usr/sbin/keyctl negate %k 30 %S を記述する

緩和策4: 非特権ユーザー名前空間を無効化する。

・Debian系: sysctl -w kernel.unprivileged_userns_clone=0 を設定し、/etc/sysctl.d/ に永続化する
・RHEL系: echo 0 > /proc/sys/user/max_user_namespaces 相当を sysctl で永続化する

名前空間の無効化は、コンテナや一部のサンドボックス機能に影響することがあります。本番に打つ前に、必ず検証機で「使っているアプリが動くか」を確認してください。「とりあえず全部止める」ではなく、自分の現場で何が CIFS と user namespace に依存しているかを把握したうえで、影響の小さい緩和から打つのが安全です。

最終的な解決は、上流コミット 3da1fdf を取り込んだカーネルへの更新です。配布元から更新が出たら速やかに適用し、緩和策はそのあとで外すかどうかを判断してください。

現場の教訓——「入れただけ」のパッケージが攻撃面になる

今回いちばん刺さったのは、「ファイル共有をマウントしたいから cifs-utils を入れた」という、ごく普通の運用判断が、そのまま root 奪取の経路になっていた点です。

攻撃の連鎖は、鍵タイプの検証漏れ・名前空間の切り替え・NSS のライブラリ差し替えという、それぞれ単体では地味な部品の組み合わせでした。19年気づかれなかったのも、1つ1つが「仕様としては動いている」からです。だからこそ、管理者にできる現実的な防御は「使っていない機能を残さない」に尽きます。CIFS を使わないなら cifs-utils を消す。コンテナを使わないなら user namespace を絞る。攻撃の前提を1つずつ削っておくだけで、次に似たクラスの脆弱性が出たとき、踏まずに済む確率が上がります。

脆弱性が公開されるたびに本番機を走り回るのではなく、「不要なものを置かない」「条件を切り分けて緩和を選ぶ」という型を、検証機で繰り返し手を動かして身につけておく。これが、CIFSwitch のような連鎖型の脆弱性に最も効く備えだと考えています。

---

• 次のページへ：Btrfs Direct I/Oがカーネル修正で約59%高速化｜SB_NOSEC抜けによる直列化を読み解く
• 前のページへ：Fedora 45がPURL導入を検討｜ソフトウェアサプライチェーン対策とSBOMをLinux管理者目線で整理
• この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る