CVE-2026-99170 in Linux情報

要約

〜によって VulDB • 2026年10月28日

Linuxカーネルにおいて、以下の脆弱性が修正されました。

namespace: copy_tree()によって除外されるマウントがロックを乗っ取ることができない

コミット c62a4766937e ("move_mount: transfer MNT_LOCKED") 以降、あるマウントはロックされたマウントの下に移動可能となりました。ロックは古いカバ(cover)から新しいマウントへと移行し、その下にあるものを隠蔽する役割を引き継ぎます。これにより、古いカバをアンマウントできます。これは新しいマウントが残っている限り正常に動作します。しかし、呼び出し元が新しいマウントを選択し、copy_tree() は CL_COPY_MNT_NS_FILE がない場合、マウントネームスペースのファイルのマウントとその上にマウントされているすべてのものをコピーから除外してしまい、MNT_LOCKED を確認しません。unshare(CLONE_NEWNS) やマウント伝播によりこのようなコピーが行われます。

したがって、独自のユーザーネームスペースで root 権限を持つタスクは、競合状態(race)なしに、かつその下のファイルシステムに触れることなく、ロックされたカバを削除できます。これは、独自のマウントネームスペースを持つ子プロセスを作成し、MOVE_MOUNT_BENEATH を使用して子プロセスの /proc/<pid>/ns/mnt をカバの下にバインドします。これによりロックがそのバインディングに移され、unshare(CLONE_NEWNS) が呼び出されます。新しいマウントネームスペースにはファイル上に何もありません。これは単一のファイルをマスクする通常の手法であり、/dev/null または空のファイルへのバインディングです。通常ファイルへのバインディングの場合、ファイルは覆われたままになります。

copy_tree() はすでにコミット df7342b24018 ("mount: Don't allow copying MNT_UNBINDABLE|MNT_LOCKED mounts") 以来、ロックされたアンマウント不可能なマウントを除外することを -EPERM で拒否しています。同様に、マウントネームスペースのファイルに対するロックされたマウントについても同じ処理を行います。これには CL_COPY_MNT_NS_FILE を使用してコピーされ、別のユーザーネームスペースのマウントネームスペースにアタッチされて lock_mnt_tree() によってロックされるツリーも含まれます。なお、unshare(CLONE_NEWNS) および clone(CLONE_NEWNS) は、このマウントネームスペースから EPERM で失敗するようになります。その結果、マウントを除外することもアンマウントすることもできなくなります。

さらに、最初からマウントネームスペースのファイルをロックされたマウントの下に移動することを拒否します。そうしないと、タスクはアンマウントできないマウントと、永久に失敗する unshare() を持つことになります。

Chris 氏はまた、自身で消去される2つ目のマウントを発見しました。これは shrink_submounts() が親とともに引き連れた自動マウントされたマウントのクローンです。コミット f78ddcc87224 ("namespace: never expire a locked mount") でこの問題は対処されました。

Chris 氏の再現コード(reproducer)を以下に示します。パッチ適用前の 7.3-rc7 では、unshare() の後に nsfile モードで SECRET が読み取られますが、本パッチにより move_mount() は EINVAL で失敗し、ファイルは覆われたままになります。nsfile-control は通常ファイルを使用し、両方の方向で MASK を読み取ります。

// SPDX-License-Identifier: GPL-2.0 /* * MOVE_MOUNT_BENEATHを使用してロックされたカバを削除する。 * * "admin" (root) が tmpfs W:を作成する。 * W/D ファイル、SECRET を保持し、MASK のファイルへのバインディングで覆われる * W/Dd/inner ファイル、SECRET を保持し、Dd は MASK を持つディレクトリへのバインディングで覆われる * "inner" が MASK を含む * W/own uid 1000 のディレクトリ。ファイル "mine" とディレクトリ "minedir" を含み、 * その "inner" は MINE を保持する * W/dbg debugfs、モード 755。dbg/tracing は自動マウントポイントである * "attacker" は uid 1000 です。新しいユーザーネームスペースと新しいマウントネームスペースに入り、W と両方のカバはそこでロックされます。 * * usage: prog MODE * plain D のカバの下に own/mine のバインディングを配置し、カバをアンマウントする * nsfile 子プロセスのマウントネームスペースファイルのバインディングを D のカバの下に配置し、unshare(CLONE_NEWNS) を呼び出す * nsfile-control own/mine のバインディングを使用するという点で上記と同じ * shrink 自動マウントされた tracefs のバインディングを Dd のカバの下に配置し、カバをアンマウントし、W の下に tmpfs を配置し、umount(W) を呼び出す(これは失敗する) * shrink-control own/minedir のバインディングを使用するという点で上記と同じ * 環境変数 AUTOMOUNT_DIR は "shrink" 用の別の自動マウントポイントを指定する。 */ #define _GNU_SOURCE #include <errno.h> #include <fcntl.h> #include <grp.h> #include <sched.h> #include <signal.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> ---truncated---

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

責任者

Linux

予約する

2026年09月25日

モデレーション

承諾済み

エントリ

VDB-427842

EPSS

0.00000

アクティビティ

非常低い

ソース

Want to know what is going to be exploited?

We predict KEV entries!