{"api_version":"1","generated_at":"2026-05-12T18:11:30+00:00","cve":"CVE-2026-43472","urls":{"html":"https://cve.report/CVE-2026-43472","api":"https://cve.report/api/cve/CVE-2026-43472.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-43472","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-43472"},"summary":{"title":"unshare: fix unshare_fs() handling","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) ;-/","state":"PUBLISHED","assigner":"Linux","published_at":"2026-05-08 15:17:00","updated_at":"2026-05-12 14:10:27"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/42e21e74061b0ebbd859839f81acf10efad02a27","name":"https://git.kernel.org/stable/c/42e21e74061b0ebbd859839f81acf10efad02a27","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/845bf3c6963a52096d0d3866e4a92db77a0c03d8","name":"https://git.kernel.org/stable/c/845bf3c6963a52096d0d3866e4a92db77a0c03d8","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/d3ffc8f13034af895531a02c30b1fe3a34b46432","name":"https://git.kernel.org/stable/c/d3ffc8f13034af895531a02c30b1fe3a34b46432","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/d7963d6997fea86a6def242ac36198b86655f912","name":"https://git.kernel.org/stable/c/d7963d6997fea86a6def242ac36198b86655f912","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/d0d99f60538ddb4a62ccaac2168d8f448965f083","name":"https://git.kernel.org/stable/c/d0d99f60538ddb4a62ccaac2168d8f448965f083","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/aa9ebc084505fb26dd90f4d7a249045aad152043","name":"https://git.kernel.org/stable/c/aa9ebc084505fb26dd90f4d7a249045aad152043","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/6c4b2243cb6c0755159bd567130d5e12e7b10d9f","name":"https://git.kernel.org/stable/c/6c4b2243cb6c0755159bd567130d5e12e7b10d9f","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/af8f4be3b68ac8caa41c8e5ead0eeaf5e85e42d0","name":"https://git.kernel.org/stable/c/af8f4be3b68ac8caa41c8e5ead0eeaf5e85e42d0","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-43472","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43472","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 741a295130606143edbf9fc740f633dbc1e6225f 845bf3c6963a52096d0d3866e4a92db77a0c03d8 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 741a295130606143edbf9fc740f633dbc1e6225f d3ffc8f13034af895531a02c30b1fe3a34b46432 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 741a295130606143edbf9fc740f633dbc1e6225f d0d99f60538ddb4a62ccaac2168d8f448965f083 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 741a295130606143edbf9fc740f633dbc1e6225f d7963d6997fea86a6def242ac36198b86655f912 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 741a295130606143edbf9fc740f633dbc1e6225f aa9ebc084505fb26dd90f4d7a249045aad152043 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 741a295130606143edbf9fc740f633dbc1e6225f af8f4be3b68ac8caa41c8e5ead0eeaf5e85e42d0 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 741a295130606143edbf9fc740f633dbc1e6225f 42e21e74061b0ebbd859839f81acf10efad02a27 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 741a295130606143edbf9fc740f633dbc1e6225f 6c4b2243cb6c0755159bd567130d5e12e7b10d9f git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 2.6.16","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 2.6.16 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 5.10.253 5.10.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 5.15.203 5.15.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.1.167 6.1.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.6.130 6.6.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.78 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.19 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.19.9 6.19.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.0 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":{"cve_year":"2026","cve_id":"43472","cve":"CVE-2026-43472","epss":"0.000240000","percentile":"0.070210000","score_date":"2026-05-11","updated_at":"2026-05-12 00:01:17"},"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["kernel/fork.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"845bf3c6963a52096d0d3866e4a92db77a0c03d8","status":"affected","version":"741a295130606143edbf9fc740f633dbc1e6225f","versionType":"git"},{"lessThan":"d3ffc8f13034af895531a02c30b1fe3a34b46432","status":"affected","version":"741a295130606143edbf9fc740f633dbc1e6225f","versionType":"git"},{"lessThan":"d0d99f60538ddb4a62ccaac2168d8f448965f083","status":"affected","version":"741a295130606143edbf9fc740f633dbc1e6225f","versionType":"git"},{"lessThan":"d7963d6997fea86a6def242ac36198b86655f912","status":"affected","version":"741a295130606143edbf9fc740f633dbc1e6225f","versionType":"git"},{"lessThan":"aa9ebc084505fb26dd90f4d7a249045aad152043","status":"affected","version":"741a295130606143edbf9fc740f633dbc1e6225f","versionType":"git"},{"lessThan":"af8f4be3b68ac8caa41c8e5ead0eeaf5e85e42d0","status":"affected","version":"741a295130606143edbf9fc740f633dbc1e6225f","versionType":"git"},{"lessThan":"42e21e74061b0ebbd859839f81acf10efad02a27","status":"affected","version":"741a295130606143edbf9fc740f633dbc1e6225f","versionType":"git"},{"lessThan":"6c4b2243cb6c0755159bd567130d5e12e7b10d9f","status":"affected","version":"741a295130606143edbf9fc740f633dbc1e6225f","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["kernel/fork.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"2.6.16"},{"lessThan":"2.6.16","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"5.10.*","status":"unaffected","version":"5.10.253","versionType":"semver"},{"lessThanOrEqual":"5.15.*","status":"unaffected","version":"5.15.203","versionType":"semver"},{"lessThanOrEqual":"6.1.*","status":"unaffected","version":"6.1.167","versionType":"semver"},{"lessThanOrEqual":"6.6.*","status":"unaffected","version":"6.6.130","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.78","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.19","versionType":"semver"},{"lessThanOrEqual":"6.19.*","status":"unaffected","version":"6.19.9","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.0","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"5.10.253","versionStartIncluding":"2.6.16","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"5.15.203","versionStartIncluding":"2.6.16","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.1.167","versionStartIncluding":"2.6.16","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.6.130","versionStartIncluding":"2.6.16","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.78","versionStartIncluding":"2.6.16","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.19","versionStartIncluding":"2.6.16","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.19.9","versionStartIncluding":"2.6.16","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.0","versionStartIncluding":"2.6.16","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"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) ;-/"}],"providerMetadata":{"dateUpdated":"2026-05-11T22:25:16.258Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"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"}],"title":"unshare: fix unshare_fs() handling","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-43472","datePublished":"2026-05-08T14:22:31.556Z","dateReserved":"2026-05-01T14:12:56.011Z","dateUpdated":"2026-05-11T22:25:16.258Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-05-08 15:17:00","lastModifiedDate":"2026-05-12 14:10:27","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"43472","Ordinal":"1","Title":"unshare: fix unshare_fs() handling","CVE":"CVE-2026-43472","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"43472","Ordinal":"1","NoteData":"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) ;-/","Type":"Description","Title":"unshare: fix unshare_fs() handling"}]}}}