{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.170-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.85-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.19.10-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003efs hadn't been shared at all; in that case copy_mnt_ns() gets passed current-\u003efs instead of a private copy, which causes interesting warts in proof of correctness]  \u003e I guess if private means fs-\u003eusers == 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-\u003efs-\u003eusers == 1).  We pass current-\u003efs to copy_mnt_ns(), all right.  Suppose it succeeds and flips current-\u003efs-\u003e{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-\u003efs-\u003eroot and current-\u003efs-\u003epwd 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) ;-/",
  "id": "DEBIAN-CVE-2026-43472",
  "modified": "2026-09-14T16:47:35.770868917Z",
  "published": "2026-05-08T15:17:00.313Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-43472"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-43472"
  ]
}