製品・ソフトウェアに関する情報
Vulnerability Search
LinuxのLinux Kernelにおける初期化されていないリソースの使用に関する脆弱性
Title LinuxのLinux Kernelにおける初期化されていないリソースの使用に関する脆弱性
Summary

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)が導入されて以来存在していました。

Possible impacts 当該ソフトウェアが扱う情報について、外部への漏えいは発生しません。 また、当該ソフトウェアが扱う情報について、書き換えは発生しません。 さらに、当該ソフトウェアが完全に停止する可能性があります。 そして、この脆弱性を悪用した攻撃の影響は、他のソフトウェアには及びません。 
Solution

リリース情報、またはパッチ情報が公開されています。参考情報を参照して適切な対策を実施してください。

Publication Date May 8, 2026, midnight
Registration Date May 25, 2026, 10:20 a.m.
Last Update May 25, 2026, 10:20 a.m.
CVSS3.0 : 警告
Score 5.5
Vector CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Affected System
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
CVE (情報セキュリティ 共通脆弱性識別子)
CWE (共通脆弱性タイプ一覧)
その他
Change Log
No Changed Details Date of change
1 [2026年05月25日]
  掲載		 May 25, 2026, 10:20 a.m.
NVD Vulnerability Information
CVE-2026-43472
Summary

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
CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that
case copy_mnt_ns() gets passed current->fs instead of a private copy,
which causes interesting warts in proof of correctness]

> 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.
Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS
(and current->fs->users == 1).

We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and
flips current->fs->{pwd,root} to corresponding locations in the new namespace.
Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM).
We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's
destroyed and its mount tree is dissolved, but... current->fs->root and
current->fs->pwd are both left pointing to now detached mounts.

They are pinning those, so it's not a UAF, but it leaves the calling
process with unshare(2) failing with -ENOMEM _and_ leaving it with
pwd and root on detached isolated mounts. The last part is clearly a bug.

There is other fun related to that mess (races with pivot_root(), including
the one between pivot_root() and fork(), of all things), but this one
is easy to isolate and fix - treat CLONE_NEWNS as "allocate a new
fs_struct even if it hadn't been shared in the first place". Sure, we could
go for something like "if both CLONE_NEWNS *and* one of the things that might
end up failing after copy_mnt_ns() call in create_new_namespaces() are set,
force allocation of new fs_struct", but let's keep it simple - the cost
of copy_fs_struct() is trivial.

Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets
a freshly allocated fs_struct, yet to be attached to anything. That
seriously simplifies the analysis...

FWIW, that bug had been there since the introduction of unshare(2) ;-/

Publication Date May 9, 2026, 12:17 a.m.
Registration Date May 9, 2026, 4:15 a.m.
Last Update May 12, 2026, 11:10 p.m.
Related information, measures and tools
Common Vulnerabilities List