unshare: fix unshare_fs() handling

MITRE NVD CVE.ORG JSON API Print: PDF PDF

Summary

CVECVE-2026-43472
StatePUBLISHED
AssignerLinux
Source PriorityCVE Program / NVD first with legacy fallback
Published2026-05-08 15:17:00 UTC
Updated2026-05-12 14:10:27 UTC
DescriptionIn 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) ;-/

Risk And Classification

EPSS: 0.000240000 probability, percentile 0.070210000 (date 2026-05-11)

Vendor Declared Affected Products

SourceVendorProductVersionPlatforms
CNA Linux Linux affected 741a295130606143edbf9fc740f633dbc1e6225f 845bf3c6963a52096d0d3866e4a92db77a0c03d8 git Not specified
CNA Linux Linux affected 741a295130606143edbf9fc740f633dbc1e6225f d3ffc8f13034af895531a02c30b1fe3a34b46432 git Not specified
CNA Linux Linux affected 741a295130606143edbf9fc740f633dbc1e6225f d0d99f60538ddb4a62ccaac2168d8f448965f083 git Not specified
CNA Linux Linux affected 741a295130606143edbf9fc740f633dbc1e6225f d7963d6997fea86a6def242ac36198b86655f912 git Not specified
CNA Linux Linux affected 741a295130606143edbf9fc740f633dbc1e6225f aa9ebc084505fb26dd90f4d7a249045aad152043 git Not specified
CNA Linux Linux affected 741a295130606143edbf9fc740f633dbc1e6225f af8f4be3b68ac8caa41c8e5ead0eeaf5e85e42d0 git Not specified
CNA Linux Linux affected 741a295130606143edbf9fc740f633dbc1e6225f 42e21e74061b0ebbd859839f81acf10efad02a27 git Not specified
CNA Linux Linux affected 741a295130606143edbf9fc740f633dbc1e6225f 6c4b2243cb6c0755159bd567130d5e12e7b10d9f git Not specified
CNA Linux Linux affected 2.6.16 Not specified
CNA Linux Linux unaffected 2.6.16 semver Not specified
CNA Linux Linux unaffected 5.10.253 5.10.* semver Not specified
CNA Linux Linux unaffected 5.15.203 5.15.* semver Not specified
CNA Linux Linux unaffected 6.1.167 6.1.* semver Not specified
CNA Linux Linux unaffected 6.6.130 6.6.* semver Not specified
CNA Linux Linux unaffected 6.12.78 6.12.* semver Not specified
CNA Linux Linux unaffected 6.18.19 6.18.* semver Not specified
CNA Linux Linux unaffected 6.19.9 6.19.* semver Not specified
CNA Linux Linux unaffected 7.0 * original_commit_for_fix Not specified

References

ReferenceSourceLinkTags
git.kernel.org/stable/c/42e21e74061b0ebbd859839f81acf10efad02a27 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/845bf3c6963a52096d0d3866e4a92db77a0c03d8 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/d3ffc8f13034af895531a02c30b1fe3a34b46432 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/d7963d6997fea86a6def242ac36198b86655f912 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/d0d99f60538ddb4a62ccaac2168d8f448965f083 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/aa9ebc084505fb26dd90f4d7a249045aad152043 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/6c4b2243cb6c0755159bd567130d5e12e7b10d9f 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/af8f4be3b68ac8caa41c8e5ead0eeaf5e85e42d0 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
CVE Program record CVE.ORG www.cve.org canonical
NVD vulnerability detail NVD nvd.nist.gov canonical, analysis
© CVE.report 2026 |

Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. It is the responsibility of user to evaluate the accuracy, completeness or usefulness of any information, opinion, advice or other content. EACH USER WILL BE SOLELY RESPONSIBLE FOR ANY consequences of his or her direct or indirect use of this web site. ALL WARRANTIES OF ANY KIND ARE EXPRESSLY DISCLAIMED. This site will NOT BE LIABLE FOR ANY DIRECT, INDIRECT or any other kind of loss.

CVE, CWE, and OVAL are registred trademarks of The MITRE Corporation and the authoritative source of CVE content is MITRE's CVE web site. This site includes MITRE data granted under the following license.

Free CVE JSON API cve.report/api

CVE.report and Source URL Uptime Status status.cve.report