CVE-2026-98993 in Linux
要約
〜によって VulDB • 2026年10月23日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
namespace: clone_mnt() における MNT_UMOUNT の継承を防止する
MNT_UMOUNT フラグは、umount_tree() または umount_one() によって名前空間から切り離されたマウントに対して設定されます。このフラグは決してクリアされません。__detach_mounts() はアンマウントを行うのではなく、当該フラグを持つマウントの接続を解除します。
disconnect_mount() は、親が MNT_UMOUNT フラグを持っている場合に限り、アンマウント済みの子マウントを接続状態のままにしておきます。propagate_umount() は、どのマウントをアンマウントできるか、ロックされたマウントのチェーンの終了位置、およびオーバーマウントのリペアレンティング（親変更）を行う際に、このフラグを「マウントがアンマウントされようとしている」ことを示すシグナルとして扱います。
clone_mnt() はソースのマウントフラグをコピーしますが、MNT_INTERNAL_FLAGS のみをマスクします。これには MNT_UMOUNT は含まれていませんでした。ファイル記述子によって生存が維持されているラジカルアンマウント（lazy unmount）済みのマウントでも、そのルートが nsfs または pidfs ファイルである場合、may_copy_tree() がソースが実際にマウントされているかどうかをチェックする前にこれらのファイルを許可するため、コピーされることがありました：
mount --bind /proc/self/ns/net /tmp/x exec 3< /tmp/x umount -l /tmp/x mount --bind /proc/self/fd/3 /tmp/y
/tmp/y のマウントは呼び出し元の名前空間に接続され、MNT_UMOUNT フラグが既に設定されています。そのコピーを作成するたびにこのフラグが再び継承されます。
これにより、以下の多数のバグが発生します：
- マウントポイントのマウント名前空間外からアンリンクを行うと、__detach_mounts() はこれを以前にアンマウントされたマウントとして扱い、親からの接続を解除し、名前空間が保持している参照カウントを解放してしまいます。結果として、このマウントは名前空間内に残りつつも参照数が1つ不足した状態になり、かつ自身の親となるため、ファイル記述子を通じてアンマウントできなくなり、名前空間から二度と検出されなくなります。名前空間が消滅するとリークが発生し、freed struct mnt_namespace を指すようになりますが、これは次の伝播変更時やファイル記述子を通じた mount_setattr() 実行時に may_change_propagation() や anon_ns_root() が読み取る可能性があります。
- マウントを共有（shared）状態にし、ピアマウントをアンマウントしようとすると、trace_transfers() はフラグを追ってそのピアに到達し、ピアグループからフラグを取り除いてしまいます。
- 伝播された umount をこれに到達させてしまうと、gather_candidates() は T_UMOUNT_CANDIDATE マークを設定しますが、候補リストには追加しないため、このマークはクリアされず、後続のすべての伝播される umount がこれをスキップしてしまいます。もしこれがロックされたマウントの親である場合、handle_locked() はこれを境界として扱い、本来残すべきだったロックされた子マウントをコミットしてしまい、disconnect_mount() はその子を接続済みの親の下にアンマウント済みで接続したままにしてしまいます（これは disconnect_mount() が防止しようとしている状態です）。名前空間が消滅すると umount_tree() が子供を2回目に訪れます。また、__detach_mounts() によってそれが自身の親となった後、reparent() はアンマウントされた親のチェーンの終端を見つけることができなくなります。
クローン（clone）は、一度もアンマウントされていない新しいマウントです。MNT_UMOUNT を MNT_INTERNAL_FLAGS に追加し、clone_mnt() がこれをコピーしないようにします。また、umount_tree() が既にこのフラグが設定されたマウントに到達した場合に警告を発するようにします。
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.