CVE-2026-43472: unshare: fix unshare_fs() handling
In the Linux kernel, the following vulnerability has been resolved:
unshare: fix unsharefs() handling
There's an unpleasant corner case in unshare(2), when we have a CLONENEWNS in flags and current->fs hadn't been shared at all; in that case copymntns() 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 CLONENEWCGROUP in addition to CLONENEWNS (and current->fs->users == 1).
We pass current->fs to copymntns(), all right. Suppose it succeeds and flips current->fs->{pwd,root} to corresponding locations in the new namespace. Now we proceed to copycgroupns(), which fails (e.g. with -ENOMEM). We call putmntns() on the namespace created by copymntns(), 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 pivotroot(), including the one between pivotroot() and fork(), of all things), but this one is easy to isolate and fix - treat CLONENEWNS as "allocate a new fsstruct even if it hadn't been shared in the first place". Sure, we could go for something like "if both CLONENEWNS and one of the things that might end up failing after copymntns() call in createnewnamespaces() are set, force allocation of new fsstruct", but let's keep it simple - the cost of copyfsstruct() is trivial.
Another benefit is that copymntns() with CLONENEWNS always gets a freshly allocated fsstruct, yet to be attached to anything. That seriously simplifies the analysis...
FWIW, that bug had been there since the introduction of unshare(2) ;-/
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2026-43472?
CVE-2026-43472 is classified as a medium severity vulnerability in the Linux kernel.
How do I fix CVE-2026-43472?
To fix CVE-2026-43472, you should update to the latest version of the Linux kernel where the vulnerability is resolved.
What does CVE-2026-43472 affect?
CVE-2026-43472 affects the unshare functionality in the Linux kernel.
What is the nature of the issue in CVE-2026-43472?
CVE-2026-43472 involves a corner case in the unshare_fs() handling when using CLONE_NEWNS in flags.
Who is affected by CVE-2026-43472?
Any system running a vulnerable version of the Linux kernel that utilizes the unshare functionality may be affected by CVE-2026-43472.