Skip to main content

Linux Kernel EUVDEUVD-2026-28778

| CVE-2026-43472 MEDIUM
Use of Uninitialized Resource (CWE-908)
2026-05-08 Linux GHSA-vgv8-2mh4-qh7r
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
SUSE
MEDIUM
qualitative
Red Hat
5.5 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

4
Analysis Generated
May 21, 2026 - 13:53 vuln.today
CVSS changed
May 21, 2026 - 13:52 NVD
5.5 (MEDIUM)
Patch available
May 08, 2026 - 16:18 EUVD
CVE Published
May 08, 2026 - 14:22 nvd
UNKNOWN (no severity yet)

DescriptionCVE.org

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) ;-/

AnalysisAI

Improper error-path state management in the Linux kernel's unshare(2) syscall leaves calling processes with dangling filesystem root and working-directory pointers after partial namespace creation failure. When a local low-privileged process calls unshare() with both CLONE_NEWNS and CLONE_NEWCGROUP on an unshared fs_struct (users==1), a successful copy_mnt_ns() updates current->fs->root and current->fs->pwd into the new mount namespace before a subsequent copy_cgroup_ns() failure triggers cleanup - dissolving the mount tree while leaving those pointers referencing now-detached mounts. The calling process is stranded in a broken filesystem state, producing high availability impact (CVSS A:H) confined entirely to the calling process. No public exploit has been identified, EPSS is 0.02% (7th percentile), and this is not in CISA KEV, reflecting low real-world exploitation interest despite the bug existing since unshare(2) was first introduced.

Technical ContextAI

The vulnerability resides in the Linux kernel's namespace unsharing logic, specifically the interaction between unshare_fs(), copy_mnt_ns(), and create_new_namespaces(). CWE-908 (Use of Uninitialized Resource) characterizes the root cause: when CLONE_NEWNS is requested and current->fs->users == 1, unshare_fs() determines no private copy is needed and passes current->fs directly to copy_mnt_ns(). If copy_mnt_ns() succeeds, it flips current->fs->{pwd,root} to locations within the newly created mount namespace. When a subsequent namespace operation such as copy_cgroup_ns() then fails (e.g., -ENOMEM), the cleanup path calls put_mnt_ns() which dissolves the mount tree - but the already-modified fs_struct pointers are never rolled back, leaving them referencing freed and now-detached mount structures. The fix forces allocation of a fresh fs_struct via copy_fs_struct() whenever CLONE_NEWNS is present, ensuring copy_mnt_ns() always receives a throwaway structure that is safe to discard on failure. Affected scope is broad per CPE cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:*, covering all kernel versions from unshare(2) introduction through the patched stable releases.

RemediationAI

The primary fix is to upgrade to a patched Linux kernel stable release: 5.10.253, 5.15.203, 6.1.167, 6.6.130, 6.12.78, 6.18.19, 6.19.9, or 7.0, as confirmed by the Linux kernel stable maintainers via commits at https://git.kernel.org/stable/c/845bf3c6963a52096d0d3866e4a92db77a0c03d8 and related references. Distribution vendors (RHEL, Debian, Ubuntu, SUSE) should be monitored for backported patches to their specific kernel versions. If immediate patching is not feasible, a compensating control is to restrict unprivileged namespace creation by setting kernel.unprivileged_userns_clone=0 (available on distributions such as Debian and Ubuntu) via sysctl - trade-off: this disables user namespace creation for non-root processes, breaking some container runtimes and sandboxing tools (Podman rootless, Bubblewrap, Chrome sandbox). Alternatively, deploy seccomp or AppArmor/SELinux policies to deny CLONE_NEWNS and CLONE_NEWCGROUP syscall flag combinations for untrusted processes. Since the attack vector is strictly local (AV:L), hardening SSH access and limiting interactive shell accounts to trusted users significantly reduces exposure without kernel changes.

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

EUVD-2026-28778 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy