CVE-2026-43472

What it actually does

This is a local Linux kernel flaw in unshare(2) namespace handling. When a process calls unshare() with CLONE_NEWNS and an additional namespace operation that can fail later, such as CLONE_NEWCGROUP, the kernel may pass the caller's current fs_struct into mount namespace creation instead of using a fresh copy. If a later namespace setup step fails, for example due to memory pressure, cleanup destroys the newly created mount namespace while the calling process's root and current working directory still point at detached mounts. The issue is not described as a use-after-free, but it can leave the process in an inconsistent filesystem namespace state and cause availability impact to the affected process or workload.

Why it matters to the business

An attacker or untrusted local workload with the ability to execute code on an affected Linux system can trigger abnormal filesystem namespace behavior that may disrupt applications, containers, build jobs, or multi-tenant workloads relying on namespace isolation. The impact is primarily operational availability: affected processes may fail, become isolated from the expected filesystem view, or behave unpredictably. Because exploitation requires local privileges and there is no known public exploitation or KEV listing, urgency is lower than for remotely exploitable kernel bugs, but shared Linux hosts, container platforms, CI runners, and systems allowing untrusted local code should prioritize kernel updates.

How an attack unfolds

An attacker first obtains the ability to run a local process on an affected Linux kernel, such as through a shell account, compromised service, container workload, CI job, or sandboxed execution environment. The attacker invokes unshare(2) with CLONE_NEWNS to create a new mount namespace and combines it with another namespace flag whose setup can fail after mount namespace creation, such as CLONE_NEWCGROUP. By arranging or waiting for a failure condition such as memory allocation failure during later namespace setup, the kernel unwinds the partially created namespace incorrectly. The cleanup detaches the newly created mount tree while the process remains with root and current working directory references into the detached namespace. The attacker can repeat this behavior to disrupt the calling workload, interfere with namespace-dependent operations, or contribute to localized denial of service on systems that run untrusted local workloads.

How to fix it

Apply a Linux kernel update containing the upstream fix for unshare_fs() handling. The corrected behavior is to allocate a new fs_struct whenever CLONE_NEWNS is requested, even when the caller's fs_struct is not shared, so failed later namespace creation does not corrupt the caller's filesystem context. No exact fixed package versions were provided in the input; use the fixed kernel packages from the operating system or appliance vendor for all affected Linux distributions. Where immediate patching is not possible, reduce exposure by limiting local code execution, restricting unprivileged namespace creation where operationally feasible, constraining container and CI workloads, enforcing memory and process limits, and applying seccomp/AppArmor/SELinux policies that block or limit unshare(2) for untrusted workloads.

How to confirm the fix worked

Confirm the running kernel version is at or above the vendor-fixed release for this issue, not merely that an updated package is installed. Validate with commands such as uname -r and the distribution package manager, then reboot into the fixed kernel if required. On source-based or custom kernels, verify the unshare_fs() fix is present and that CLONE_NEWNS forces allocation of a new fs_struct before copy_mnt_ns() is called. Functional validation can include a controlled regression test that exercises unshare(CLONE_NEWNS | CLONE_NEWCGROUP) under constrained resources and confirms failed unshare calls do not leave the process with root or current working directory on detached mounts. Also verify any compensating controls by confirming untrusted users or containers cannot invoke unshare(2) with mount namespace creation if that mitigation is intended.

Typical attack path

1. Gain local code execution on an affected Linux system, container host, shared server, or CI/build runner.
2. Run a process that calls unshare(2) with CLONE_NEWNS and an additional namespace flag such as CLONE_NEWCGROUP.
3. Induce or rely on a later namespace creation failure, commonly through memory pressure or resource exhaustion conditions.
4. Trigger the flawed cleanup path after mount namespace creation succeeds but a later namespace operation fails.
5. Leave the calling process with root and current working directory references to detached mounts, causing abnormal filesystem namespace behavior and availability impact.
6. Repeat the operation or combine it with workload-specific behavior to disrupt local services, containers, or jobs.

How to detect it

Look for evidence of local attempts to create namespaces with unshare(2), especially repeated calls using mount namespace creation combined with cgroup namespace creation and failures around the same time. Useful sources include Linux auditd syscall logs, eBPF syscall telemetry, endpoint detection telemetry, container runtime logs, Kubernetes node logs, CI runner logs, kernel logs, and systemd journal entries. Investigate sequences showing unshare failures, ENOMEM or resource exhaustion, container/job crashes, abnormal mount namespace behavior, or processes reporting inaccessible current working directories after failed namespace operations. Because the bug does not define a stable file artifact, network indicator, or persistent malware behavior, detection should focus on behavioral telemetry: repeated unshare syscall use by unexpected users or workloads, failures in namespace setup, and correlated memory pressure. If named threat actors or public exploit campaigns are absent, treat findings as suspicious local activity requiring host-level triage rather than as definitive compromise.

• syscall=unshare
• comm="unshare"
• unshare(CLONE_NEWNS
• CLONE_NEWNS|CLONE_NEWCGROUP
• CLONE_NEWNS | CLONE_NEWCGROUP
• unshare: unshare failed: Cannot allocate memory
• unshare: unshare failed: Operation not permitted
• ENOMEM
• kernel.unprivileged_userns_clone
• /proc/sys/kernel/unprivileged_userns_clone
• No such file or directory: getcwd
• getcwd: cannot access parent directories

What your security team should do

• Inventory Linux systems that allow local shell access, container execution, CI jobs, sandboxed workloads, or other untrusted code execution.
• Prioritize kernel updates for shared hosts, container platforms, Kubernetes nodes, CI/CD runners, developer workstations running untrusted builds, and multi-user servers.
• Reboot systems after installing fixed kernel packages and verify the active kernel is the fixed version.
• If patching is delayed, disable or restrict unprivileged namespace creation where feasible, including controls such as kernel.unprivileged_userns_clone on distributions that support it.
• Use seccomp, AppArmor, SELinux, container runtime profiles, or workload policies to restrict unshare(2), especially CLONE_NEWNS and CLONE_NEWCGROUP, for untrusted workloads.
• Monitor for repeated unshare failures, namespace creation errors, memory-pressure events, and abnormal container/job failures that could indicate attempted triggering.
• Ensure resource limits are in place for untrusted workloads to reduce the ability to induce memory allocation failures during namespace creation.
• Track vendor advisories for exact fixed kernel package versions because none were provided in the source data.