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 CLONENEWNS in flags and current->fs hadn't been shared at all; in that case copymnt_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 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) ;-/
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/43xxx/CVE-2026-43472.json",
"cna_assigner": "Linux"
}