{"id":"CVE-2026-43472","title":"unshare: fix unshare_fs() handling","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nunshare: fix unshare_fs() handling\n\nThere's an unpleasant corner case in unshare(2), when we have a\nCLONE_NEWNS in flags and current->fs hadn't been shared at all; in t…","severity":"none","vendor":"Linux","product":"Linux","affected":["Linux >= 741a295130606143edbf9fc740f633dbc1e6225f < 845bf3c6963a52096d0d3866e4a92db77a0c03d8","Linux >= 741a295130606143edbf9fc740f633dbc1e6225f < d3ffc8f13034af895531a02c30b1fe3a34b46432","Linux >= 741a295130606143edbf9fc740f633dbc1e6225f < d0d99f60538ddb4a62ccaac2168d8f448965f083","Linux >= 741a295130606143edbf9fc740f633dbc1e6225f < d7963d6997fea86a6def242ac36198b86655f912","Linux >= 741a295130606143edbf9fc740f633dbc1e6225f < aa9ebc084505fb26dd90f4d7a249045aad152043","Linux >= 741a295130606143edbf9fc740f633dbc1e6225f < af8f4be3b68ac8caa41c8e5ead0eeaf5e85e42d0","Linux >= 741a295130606143edbf9fc740f633dbc1e6225f < 42e21e74061b0ebbd859839f81acf10efad02a27","Linux >= 741a295130606143edbf9fc740f633dbc1e6225f < 6c4b2243cb6c0755159bd567130d5e12e7b10d9f","Linux 2.6.16"],"ssvc":{"exploitation":"none","automatable":"no","technicalImpact":"partial","timestamp":"2026-11-06T15:39:35.857143Z"},"published":"2026-05-08","updated":"2026-11-06","sourceUpdated":"2026-11-06T15:42:56.209Z","source":"CVEORG","sourceUrl":"https://www.cve.org/CVERecord?id=CVE-2026-43472","references":[{"url":"https://git.kernel.org/stable/c/845bf3c6963a52096d0d3866e4a92db77a0c03d8"},{"url":"https://git.kernel.org/stable/c/d3ffc8f13034af895531a02c30b1fe3a34b46432"},{"url":"https://git.kernel.org/stable/c/d0d99f60538ddb4a62ccaac2168d8f448965f083"},{"url":"https://git.kernel.org/stable/c/d7963d6997fea86a6def242ac36198b86655f912"},{"url":"https://git.kernel.org/stable/c/aa9ebc084505fb26dd90f4d7a249045aad152043"},{"url":"https://git.kernel.org/stable/c/af8f4be3b68ac8caa41c8e5ead0eeaf5e85e42d0"},{"url":"https://git.kernel.org/stable/c/42e21e74061b0ebbd859839f81acf10efad02a27"},{"url":"https://git.kernel.org/stable/c/6c4b2243cb6c0755159bd567130d5e12e7b10d9f"}],"tags":["cve.org"],"epss":0.00114,"epssPercentile":0.01501,"ingestedAt":"2026-11-06T15:54:03.903Z","slug":"CVE-2026-43472","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nunshare: fix unshare_fs() handling\n\nThere's an unpleasant corner case in unshare(2), when we have a\nCLONE_NEWNS in flags and current->fs hadn't been shared at all; in that\ncase copy_mnt_ns() gets passed current->fs instead of a private copy,\nwhich causes interesting warts in proof of correctness]\n\n> I guess if private means fs->users == 1, the condition could still be true.\n\nUnfortunately, it's worse than just a convoluted proof of correctness.\nConsider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS\n(and current->fs->users == 1).\n\nWe pass current->fs to copy_mnt_ns(), all right.  Suppose it succeeds and\nflips current->fs->{pwd,root} to corresponding locations in the new namespace.\nNow we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM).\nWe call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's\ndestroyed and its mount tree is dissolved, but...  current->fs->root and\ncurrent->fs->pwd are both left pointing to now detached mounts.\n\nThey are pinning those, so it's not a UAF, but it leaves the calling\nprocess with unshare(2) failing with -ENOMEM _and_ leaving it with\npwd and root on detached isolated mounts.  The last part is clearly a bug.\n\nThere is other fun related to that mess (races with pivot_root(), including\nthe one between pivot_root() and fork(), of all things), but this one\nis easy to isolate and fix - treat CLONE_NEWNS as \"allocate a new\nfs_struct even if it hadn't been shared in the first place\".  Sure, we could\ngo for something like \"if both CLONE_NEWNS *and* one of the things that might\nend up failing after copy_mnt_ns() call in create_new_namespaces() are set,\nforce allocation of new fs_struct\", but let's keep it simple - the cost\nof copy_fs_struct() is trivial.\n\nAnother benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets\na freshly allocated fs_struct, yet to be attached to anything.  That\nseriously simplifies the analysis...\n\nFWIW, that bug had been there since the introduction of unshare(2) ;-/\n\n## Affected\n\n- `Linux >= 741a295130606143edbf9fc740f633dbc1e6225f < 845bf3c6963a52096d0d3866e4a92db77a0c03d8`\n- `Linux >= 741a295130606143edbf9fc740f633dbc1e6225f < d3ffc8f13034af895531a02c30b1fe3a34b46432`\n- `Linux >= 741a295130606143edbf9fc740f633dbc1e6225f < d0d99f60538ddb4a62ccaac2168d8f448965f083`\n- `Linux >= 741a295130606143edbf9fc740f633dbc1e6225f < d7963d6997fea86a6def242ac36198b86655f912`\n- `Linux >= 741a295130606143edbf9fc740f633dbc1e6225f < aa9ebc084505fb26dd90f4d7a249045aad152043`\n- `Linux >= 741a295130606143edbf9fc740f633dbc1e6225f < af8f4be3b68ac8caa41c8e5ead0eeaf5e85e42d0`\n- `Linux >= 741a295130606143edbf9fc740f633dbc1e6225f < 42e21e74061b0ebbd859839f81acf10efad02a27`\n- `Linux >= 741a295130606143edbf9fc740f633dbc1e6225f < 6c4b2243cb6c0755159bd567130d5e12e7b10d9f`\n- `Linux 2.6.16`\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"sunlit","depthScore":3,"depthScoreParts":{"impact":2.8,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}