CVE-2026-98989 in Linux
要約
〜によって VulDB • 2026年10月24日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
namespace: マウントネームスペースの循環に対する再帰的なbindマウントの確認
do_loopback()は、呼び出し元のプロセスよりも古いかそれと同等のマウントネームスペースのファイルに対してbindマウントを行うことを拒否します。これは、自身のファイルや祖先のファイルを保持するマウントネームスペースがサイクル（ループ）を引き起こす可能性があるためです。しかし、この関数は現在、bindマウントの起点となるdentryのみをチェックしています。MS_RECフラグを使用すると、その配下のすべてがコピーされ、do_loopback()はCL_COPY_MNT_NS_FILEを渡すため、ソースより下位にあるマウントネームスペースファイルもコピーされます。
これは呼び出し元自身のマウントネームスペース内のソースに対しては問題ありません。そこにあるすべてのマウントネームスペースファイルは、bindマウントされた際に同じチェックを通過しています。しかし、他のマウントネームスペースに存在するソースにとっては適切ではありません。may_copy_tree()は、/proc/<pid>/ns/<ns>やpidfdsがbindマウントできるようにするため、どのマウントネームスペースに属しているかに関係なく、任意のnsfsまたはpidfsファイルに対するbindマウントを受け入れます。もし私たちがマウントネームスペースファイル記述子のbindマウントスタックを作成すると、カーネルはそれらが対象のマウントネームスペースとの祖先関係にかかわらずコピーします：
151 146 0:7 net:[4026531833] /tmp/nrc/y rw - nsfs nsfs rw
152 151 0:7 mnt:[4026532293] /tmp/nrc/y rw - nsfs nsfs rw
マウント152は、マウントネームスペース4026532293内部のマウントネームスペースファイルに対するマウントです。そのネームスペースおよびそこにあるすべてのマウントがリークします... 古いマウントネームスペースに存在するプロセスがこのファイルをスタックし、それを繰り返すだけで無制限にリークが発生します：
コントロール後: Shmem: 380 kB child: mount(/proc/self/fd/6, MS_BIND|MS_REC): ok サイクル発生後: Shmem: 65916 kB
do_move_mount()は、まさにその理由により、切り離されたツリーに対してcheck_for_nsfs_mounts()を実行します。これをgraft（接ぎ木）する前にコピーに対しても同様の処理を行います。
If you want to get best quality of vulnerability data, you may have to visit VulDB.