Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - unshare:unshare_fs() 処理を修正します。フラグにCLONE_NEWNSがあり、current->fs がまったく共有されていない場合、unshare(2) に不快なコーナーケースがあります。その場合、copy_mnt_ns()はプライベートコピーの代わりにcurrent->fsが渡されるため、正しさの証明で興味深いいぼが発生します>プライベートがfs->users == 1を意味する場合、条件はまだ真である可能性があると思います。残念ながら、それは単なる複雑な正しさの証明よりも悪いです。CLONE_NEWNS に加えて CLONE_NEWCGROUP がある場合 (および current->fs->users == 1) の場合を考えてみましょう。current->fs を copy_mnt_ns() に渡します。それが成功し、current->fs->{pwd,root} を新しい名前空間の対応する場所に反転したとします。次に copy_cgroup_ns() に進みますが、失敗します(例:-ENOMEM の場合)。copy_mnt_ns() によって作成された名前空間で put_mnt_ns() を呼び出すと、破棄され、マウント ツリーが解消されますが、...current->fs->root および current->fs->pwd は両方とも、今ではデタッチされたマウントを指したままになります。彼らはこれらをピン留めしているので、UAF ではありませんが、呼び出しプロセスが unshare(2) が -ENOMEM _and_ で失敗したままになり、分離された分離マウントに pwd と root が残ります。最後の部分は明らかにバグです。その混乱に関連する他の楽しみ(pivot_root()とfork()の間のものを含む、pivot_root()との競合)がありますが、これは簡単に切り分けて修正できます-CLONE_NEWNSそも共有されていなくても、新しいfs_structを割り当てるものとして扱います。確かに、create_new_namespaces()のcopy_mnt_ns()呼び出し後に失敗する可能性のあることのCLONE_NEWNSと1つの両方が設定されている場合、新しいfs_structの割り当てを強制する場合などに行くことができますが、単純にしましょう-copy_fs_struct()のコストは些細なものです。もう 1 つの利点は、CLONE_NEWNS を伴う copy_mnt_ns() は *常に* 新しく割り当てられたfs_structを取得しますが、まだ何にも添付されないことです。これにより、分析が大幅に簡素化されます... FWIW、このバグは unshare(2) の導入以来存在していました ;-/(CVE-2026-43472)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

検出

Linux Distros のパッチ未適用の脆弱性: CVE-2026-43472

medium Nessus プラグイン ID 313388

バージョン 1.8