unshare: fix unshare_fs() handling
Key facts
- Attack vector
- Local
- Privileges required
- Low
- User interaction
- None
- Attack complexity
- Low
- Impact type
- Denial of service
- Confidentiality · integrity · availability
- None · None · High
- Fix status
- Partial Red Hat: 5 without a fix
Attack profile from CVSS 3.1 · NVD. Fix status from CNA and Red Hat. Impact type from CWE-908 and the CVSS impact.
Summary
In 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) ;-/
Why it matters now
SSVC decision points
CISA ADP · SSVC 2.0.3
- Exploitation
- None
- Automatable
- No
- Technical impact
- Partial
The decision (Track, Attend, Act) also depends on your mission and well-being impact; see CISA's SSVC guide.
Affected products
| Vendor | Product | Affected versions | Fixed in | Status | Source |
|---|---|---|---|---|---|
| Linux | Linux | 2.6.16 and later | 5.10.253, 5.15.203, 6.1.167, 6.6.130, 6.12.78, 6.18.19, 6.19.9, 7.0 | Patch available | CNA |
- Linux VendorLinux Affected 2.6.16 and later Fixed in 5.10.253, 5.15.203, 6.1.167, 6.6.130, 6.12.78, 6.18.19, 6.19.9, 7.0 Patch available CNA
CPE configurations NVD · 8
| CPE | Versions | Role | Vendor |
|---|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | 2.6.16.1 to before 5.10.253; 5.11 to before 5.15.203; 5.16 to before 6.1.167; 6.2 to before 6.6.130; 6.7 to before 6.12.78; 6.13 to before 6.18.19; 6.19 to before 6.19.9 | Vulnerable | Linux |
| cpe:2.3:o:linux:linux_kernel:2.6.16:-:*:*:*:*:*:* | 2.6.16 | Vulnerable | Linux |
| cpe:2.3:o:linux:linux_kernel:2.6.16:rc3:*:*:*:*:*:* | 2.6.16 rc3 | Vulnerable | Linux |
| cpe:2.3:o:linux:linux_kernel:2.6.16:rc4:*:*:*:*:*:* | 2.6.16 rc4 | Vulnerable | Linux |
| cpe:2.3:o:linux:linux_kernel:2.6.16:rc5:*:*:*:*:*:* | 2.6.16 rc5 | Vulnerable | Linux |
| cpe:2.3:o:linux:linux_kernel:2.6.16:rc6:*:*:*:*:*:* | 2.6.16 rc6 | Vulnerable | Linux |
| cpe:2.3:o:linux:linux_kernel:2.6.16:rc7:*:*:*:*:*:* | 2.6.16 rc7 | Vulnerable | Linux |
| cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:* | 7.0 rc1 | Vulnerable | Linux |
- cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* Versions 2.6.16.1 to before 5.10.253; 5.11 to before 5.15.203; 5.16 to before 6.1.167; 6.2 to before 6.6.130; 6.7 to before 6.12.78; 6.13 to before 6.18.19; 6.19 to before 6.19.9 Vulnerable ·Linux
- cpe:2.3:o:linux:linux_kernel:2.6.16:-:*:*:*:*:*:* Versions 2.6.16 Vulnerable ·Linux
- cpe:2.3:o:linux:linux_kernel:2.6.16:rc3:*:*:*:*:*:* Versions 2.6.16 rc3 Vulnerable ·Linux
- cpe:2.3:o:linux:linux_kernel:2.6.16:rc4:*:*:*:*:*:* Versions 2.6.16 rc4 Vulnerable ·Linux
- cpe:2.3:o:linux:linux_kernel:2.6.16:rc5:*:*:*:*:*:* Versions 2.6.16 rc5 Vulnerable ·Linux
- cpe:2.3:o:linux:linux_kernel:2.6.16:rc6:*:*:*:*:*:* Versions 2.6.16 rc6 Vulnerable ·Linux
- cpe:2.3:o:linux:linux_kernel:2.6.16:rc7:*:*:*:*:*:* Versions 2.6.16 rc7 Vulnerable ·Linux
- cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:* Versions 7.0 rc1 Vulnerable ·Linux
Remediation
- Fix · CNA Linux (Linux) Fixed in 5.10.253, 5.15.203, 6.1.167, 6.6.130, 6.12.78, 6.18.19, 6.19.9, 7.0
Vendor assessments
Red Hat
Red Hat rating: Moderate. Red Hat's page for this CVE →
| Product | Status | Plan or fix |
|---|---|---|
| Red Hat Enterprise Linux 10 | Affected | No fix yet: Fix deferred |
| Red Hat Enterprise Linux 6 | Affected | No fix planned: Out of support scope |
| Red Hat Enterprise Linux 7 | Affected | No fix yet: Fix deferred |
| Red Hat Enterprise Linux 8 | Affected | No fix yet: Fix deferred |
| Red Hat Enterprise Linux 9 | Affected | No fix yet: Fix deferred |
Timeline
- 2026-10-02 Threatist record created from CVE-2026-43472
- 2026-10-03 Alias added: GHSA-vgv8-2mh4-qh7r
- 2026-11-06 CISA SSVC decision points changed
References
Patch 8
- https://git.kernel.org/stable/c/845bf3c6963a52096d0d3866e4a92db77a0c03d8
- https://git.kernel.org/stable/c/d3ffc8f13034af895531a02c30b1fe3a34b46432
- https://git.kernel.org/stable/c/d0d99f60538ddb4a62ccaac2168d8f448965f083
- https://git.kernel.org/stable/c/d7963d6997fea86a6def242ac36198b86655f912
- https://git.kernel.org/stable/c/aa9ebc084505fb26dd90f4d7a249045aad152043
- https://git.kernel.org/stable/c/af8f4be3b68ac8caa41c8e5ead0eeaf5e85e42d0
- https://git.kernel.org/stable/c/42e21e74061b0ebbd859839f81acf10efad02a27
- https://git.kernel.org/stable/c/6c4b2243cb6c0755159bd567130d5e12e7b10d9f
More Linux Kernel vulnerabilities
- TI-2025-26358 tls: fix handling of zero-length records on the rx_list KEVCVSS 3.1CRITICAL 9.8
- TI-2026-38352 netfilter: bridge: make ebt_snat ARP rewrite writable KEVCVSS 3.1HIGH 8.8
- TI-2013-05264 The (1) get_user and (2) put_user API functions in the Linux kernel before 3.5.5 on the… KEVCVSS 3.1HIGH 8.8
- TI-2022-00125 Integer overflow in kernel KEVCVSS 3.1HIGH 8.4
- TI-2013-01864 The perf_swevent_init function in kernel/events/core.c in the Linux kernel before 3.8.9… KEVCVSS 3.1HIGH 8.4
- TI-2021-05514 Heap Out-Of-Bounds Write in Netfilter IP6T_SO_SET_REPLACE KEVCVSS 3.1HIGH 8.3
Sources
- CVE-2026-43472 · CVE Program
- CVE-2026-43472 · NVD
- FIRST EPSS
- GHSA-vgv8-2mh4-qh7r · GitHub Advisory Database · CC BY 4.0
- CVE-2026-43472 · Red Hat security data · CC BY 4.0
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences