{"cve":"CVE-2026-43472","nvd":{"published":"2026-05-08T15:17:00.313","modified":"2026-06-17T10:49:40.283","status":"Analyzed","description":"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 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) ;-/","cvss_v4":null,"cvss_v3":{"version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","score":5.5},"cwes":["CWE-908"],"references":["https://git.kernel.org/stable/c/42e21e74061b0ebbd859839f81acf10efad02a27","https://git.kernel.org/stable/c/6c4b2243cb6c0755159bd567130d5e12e7b10d9f","https://git.kernel.org/stable/c/845bf3c6963a52096d0d3866e4a92db77a0c03d8","https://git.kernel.org/stable/c/aa9ebc084505fb26dd90f4d7a249045aad152043","https://git.kernel.org/stable/c/af8f4be3b68ac8caa41c8e5ead0eeaf5e85e42d0"],"products":["linux:linux_kernel"],"source":"nvd","synced_at":"2026-10-19T22:33:55.586217763+00:00"},"epss":{"cve":"CVE-2026-43472","score":0.00114,"percentile":0.01472,"date":"2026-10-31"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}