CVE-2026-43472: Linux Kernel Privilege Escalation Flaw

CVE-2026-43472 Overview

CVE-2026-43472 is a Linux kernel vulnerability in the unshare(2) system call. The flaw resides in the unshare_fs() handling path within create_new_namespaces(). When a caller invokes unshare(2) with both CLONE_NEWNS and CLONE_NEWCGROUP flags, and the calling task's fs_struct has not been previously shared, the kernel passes current->fs directly to copy_mnt_ns() instead of a private copy. If a subsequent namespace allocation such as copy_cgroup_ns() fails, the unshare operation returns an error, but current->fs->root and current->fs->pwd are left pointing to detached mounts from the dissolved namespace.

Critical Impact

A failed unshare(2) call leaves the calling process with its root and working directory anchored to detached mounts, producing inconsistent filesystem state. The defect has existed since unshare(2) was introduced.

Affected Products

• Linux kernel (mainline)
• Linux kernel stable branches receiving the referenced backports
• Linux distributions packaging affected stable kernel versions

Discovery Timeline

• 2026-05-08 - CVE-2026-43472 published to NVD
• 2026-05-12 - Last updated in NVD database

Technical Details for CVE-2026-43472

Vulnerability Analysis

The defect is a logic flaw in the Linux kernel namespace allocation path. The unshare(2) syscall allows a process to detach selected execution-context elements into new namespaces. When CLONE_NEWNS is set, copy_mnt_ns() is invoked to create a new mount namespace and rebind the caller's fs_struct pwd and root to entries in that namespace.

The kernel optimizes the case where current->fs->users == 1 by skipping allocation of a private fs_struct. This optimization breaks correctness when additional namespace operations follow. If copy_cgroup_ns() or any subsequent allocation in create_new_namespaces() fails, the kernel calls put_mnt_ns() to dissolve the new mount namespace. The fs_struct fields, however, still reference dentries inside the destroyed namespace.

Root Cause

The root cause is conditional allocation of fs_struct based on the share count rather than the operation being requested. When CLONE_NEWNS is supplied, the code path assumes a private fs_struct exists, but the share-count optimization can leave the caller's original fs_struct in use. Combined with rollback handling that dissolves the new mount namespace on partial failure, the caller's pwd and root are pinned to detached mounts. The fix treats CLONE_NEWNS as an unconditional trigger for copy_fs_struct(), guaranteeing copy_mnt_ns() always receives a freshly allocated fs_struct.

Attack Vector

Exploitation requires local code execution to invoke unshare(2) with crafted flag combinations. An unprivileged process able to call unshare(CLONE_NEWNS | CLONE_NEWCGROUP) under memory pressure or other induced failure conditions can reach the inconsistent state. The vulnerability does not provide a use-after-free primitive because the detached mounts remain pinned, but it produces filesystem-context corruption that can interact poorly with subsequent pivot_root() and fork() operations. See the Linux Kernel Commit d3ffc8f13034 for the corrective patch.

Detection Methods for CVE-2026-43472

Indicators of Compromise

• Processes reporting pwd or root paths under /proc/<pid>/ that resolve to detached or unreachable mount points
• Repeated unshare(2) syscalls returning -ENOMEM followed by anomalous filesystem behavior in the calling process
• Container runtime or sandbox tools failing namespace setup with concurrent mount namespace dissolution events

Detection Strategies

• Audit kernel versions against the fixing commits listed in the kernel.org references to confirm whether the patch is present
• Monitor unshare(2) syscall telemetry via auditd or eBPF probes, correlating failed calls with subsequent process state inconsistencies
• Track unexpected put_mnt_ns() paths through tracepoints when both CLONE_NEWNS and additional namespace flags are present

Monitoring Recommendations

• Enable kernel audit rules for unshare and clone syscalls in environments running container or sandbox workloads
• Review crash and warning logs for dmesg entries referencing mount namespace teardown after failed namespace creation
• Inventory deployed kernel build hashes across hosts to identify systems lacking the stable backport

How to Mitigate CVE-2026-43472

Immediate Actions Required

• Apply the upstream stable kernel update containing the unshare_fs() correction and reboot affected hosts
• Identify all systems running kernel versions predating the referenced commits and schedule patching
• Restrict use of unprivileged user namespaces where not required for workload functionality

Patch Information

The fix has been merged into the mainline Linux kernel and backported to multiple stable branches. The fix forces allocation of a new fs_struct whenever CLONE_NEWNS is requested, regardless of the original share count. Refer to the kernel.org references for each stable branch:

• Linux Kernel Commit 42e21e74061
• Linux Kernel Commit 6c4b2243cb6
• Linux Kernel Commit 845bf3c6963
• Linux Kernel Commit aa9ebc08450
• Linux Kernel Commit af8f4be3b68
• Linux Kernel Commit d0d99f60538
• Linux Kernel Commit d3ffc8f13034
• Linux Kernel Commit d7963d6997f

Workarounds

• Disable unprivileged user namespaces by setting kernel.unprivileged_userns_clone=0 where supported, reducing attacker reach to unshare(2)
• Apply seccomp profiles in container runtimes to restrict the unshare syscall to required flag combinations
• Limit memory pressure conditions on namespace-heavy hosts to reduce the probability of triggering the failure path

# Configuration example: restrict unprivileged user namespaces via sysctl
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone=0' | sudo tee /etc/sysctl.d/99-cve-2026-43472.conf