The Linux kernel flaw involves the unshare(2) system call when a process requests a new mount namespace using CLONE_NEWNS while its current filesystem structure has not yet been isolated. The kernel erroneously passes the existing fs_struct to copy_mnt_ns, which may later move the process’s root and current working directory into the new namespace. If a subsequent namespace operation such as copy_cgroup_ns fails, the created mount namespace is destroyed while the process’s root and cwd still point to detached mounts, leaving the process with an invalid filesystem view. This can lead to application crashes or incorrect filesystem operations, representing a local denial‑of‑service condition. The vulnerability does not provide a path to privilege escalation or remote code execution. The likely attack vector is a local user executing unshare(2) with CLONE_NEWNS (optionally combined with other namespace flags) on an unpatched kernel.

All Linux kernel releases prior to the commit that introduced the fix (42e21e74061b0ebbd859839f81acf10efad02a27) are impacted. The affected range includes kernel 2.6.16 and its release candidates, as well as later stable releases through the 7.0 development snapshots listed in the CPE data. Any distribution shipping an unpatched kernel within this scope is vulnerable.

The CVSS score of 5.5 indicates moderate severity. The EPSS score is below 1%, and the vulnerability is not listed in the CISA KEV catalogue, implying a low exploitation probability under current conditions. A local attacker can trigger the issue by invoking unshare(2) with CLONE_NEWNS (and possibly other namespace flags), causing the process to fail with an error while its root and cwd become invalid. The result is a local denial‑of‑service scenario that does not expose higher privileges or remote access.