| タイトル | LinuxのLinux Kernelにおける初期化されていないリソースの使用に関する脆弱性 |
|---|---|
| 概要 | Linuxカーネルにおいて、以下の脆弱性が修正されました。unshare: unshare_fs()の処理を修正しました。unshare(2)には複雑な隅角ケースがあります。flagsにCLONE_NEWNSがあり、かつcurrent-fsがまったく共有されていなかった場合、copy_mnt_ns()にprivateなコピーではなくcurrent-fsが渡されます。これにより、正当性の証明において興味深い問題が生じます。privateがfs-users == 1を意味する場合でも、この条件は真のままである可能性があります。不幸にも、これは単に複雑な正当性の証明以上に悪い問題です。CLONE_NEWCGROUPがCLONE_NEWNSに加わり(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は切り離されたマウントを指したままです。これらは参照を保持しているためUse-After-Freeではありませんが、unshare(2)が-ENOMEMで失敗しつつ、pwdとrootが切り離された孤立したマウントを指し続けるのは明確なバグです。この問題に関連する別の問題(例:pivot_root()との競合やfork()との競合)も存在しますが、この問題は分離して簡単に修正できます。CLONE_NEWNSを「最初から共有されていなくても新しいfs_structを割り当てる」と扱う修正です。もちろん、「CLONE_NEWNSかつcreate_new_namespaces()のcopy_mnt_ns()呼び出し後に失敗する可能性のある条件がある場合に新しいfs_structを強制的に割り当てる」という方法もありますが、シンプルにしておきましょう。copy_fs_struct()のコストは微小です。もう一つの利点は、CLONE_NEWNSでのcopy_mnt_ns()は常に新規割り当ての、まだ何にも関連付けられていないfs_structを受け取るため、解析が大幅に簡単になることです。ちなみに、このバグはunshare(2)が導入されて以来存在していました。 |
| 想定される影響 | 当該ソフトウェアが扱う情報について、外部への漏えいは発生しません。 また、当該ソフトウェアが扱う情報について、書き換えは発生しません。 さらに、当該ソフトウェアが完全に停止する可能性があります。 そして、この脆弱性を悪用した攻撃の影響は、他のソフトウェアには及びません。 |
| 対策 | リリース情報、またはパッチ情報が公開されています。参考情報を参照して適切な対策を実施してください。 |
| 公表日 | 2026年5月8日0:00 |
| 登録日 | 2026年5月25日10:20 |
| 最終更新日 | 2026年5月25日10:20 |
| CVSS3.0 : 警告 | |
| スコア | 5.5 |
|---|---|
| ベクター | CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H |
| Linux |
| Linux Kernel 2.6.16 |
| Linux Kernel 2.6.16.1 以上 5.10.253 未満 |
| Linux Kernel 5.11 以上 5.15.203 未満 |
| Linux Kernel 5.16 以上 6.1.167 未満 |
| Linux Kernel 6.13 以上 6.18.19 未満 |
| Linux Kernel 6.19 以上 6.19.9 未満 |
| Linux Kernel 6.2 以上 6.6.130 未満 |
| Linux Kernel 6.7 以上 6.12.78 未満 |
| Linux Kernel 7.0 |
| No | 変更内容 | 変更日 |
|---|---|---|
| 1 | [2026年05月25日] 掲載 |
2026年5月25日10:20 |
| 概要 | In the Linux kernel, the following vulnerability has been resolved: unshare: fix unshare_fs() handling There's an unpleasant corner case in unshare(2), when we have a > I guess if private means fs->users == 1, the condition could still be true. Unfortunately, it's worse than just a convoluted proof of correctness. We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and They are pinning those, so it's not a UAF, but it leaves the calling There is other fun related to that mess (races with pivot_root(), including Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets FWIW, that bug had been there since the introduction of unshare(2) ;-/ |
|---|---|
| 公表日 | 2026年5月9日0:17 |
| 登録日 | 2026年5月9日4:15 |
| 最終更新日 | 2026年5月12日23:10 |