CVE-2026-43472: unshare: fix unshare_fs() handling

Published May 8, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

unshare: fix unsharefs() 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 copymntns() 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) ;-/

Affected Software

15 affected components
Linux Linux kernel
Linux Linux kernel>=2.6.16.1<5.10.253
Linux Linux kernel>=5.11<5.15.203
Linux Linux kernel>=5.16<6.1.167
Linux Linux kernel>=6.2<6.6.130
Linux Linux kernel>=6.7<6.12.78
Linux Linux kernel>=6.13<6.18.19
Linux Linux kernel>=6.19<6.19.9
Linux Linux kernel=2.6.16
Linux Linux kernel=2.6.16-rc3
Linux Linux kernel=2.6.16-rc4
Linux Linux kernel=2.6.16-rc5
Linux Linux kernel=2.6.16-rc6
Linux Linux kernel=2.6.16-rc7
Linux Linux kernel=7.0-rc1

Event History

May 8, 2026
CVE Published
via MITRE·02:22 PM
Data Sourced
via MITRE·02:22 PM
Description
Data Sourced
via NVD·03:17 PM
RemedyDescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2026-43472?

CVE-2026-43472 is classified as a medium severity vulnerability in the Linux kernel.

2

How do I fix CVE-2026-43472?

To fix CVE-2026-43472, you should update to the latest version of the Linux kernel where the vulnerability is resolved.

3

What does CVE-2026-43472 affect?

CVE-2026-43472 affects the unshare functionality in the Linux kernel.

4

What is the nature of the issue in CVE-2026-43472?

CVE-2026-43472 involves a corner case in the unshare_fs() handling when using CLONE_NEWNS in flags.

5

Who is affected by CVE-2026-43472?

Any system running a vulnerable version of the Linux kernel that utilizes the unshare functionality may be affected by CVE-2026-43472.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203