{
  "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:  mctp: route: hold key-\u003elock in mctp_flow_prepare_output()  mctp_flow_prepare_output() checks key-\u003edev and may call mctp_dev_set_key(), but it does not hold key-\u003elock while doing so.  mctp_dev_set_key() and mctp_dev_release_key() are annotated with __must_hold(\u0026key-\u003elock), so key-\u003edev access is intended to be serialized by key-\u003elock. The mctp_sendmsg() transmit path reaches mctp_flow_prepare_output() via mctp_local_output() -\u003e mctp_dst_output() without holding key-\u003elock, so the check-and-set sequence is racy.  Example interleaving:    CPU0                                  CPU1   ----                                  ----   mctp_flow_prepare_output(key, devA)     if (!key-\u003edev)  // sees NULL                                         mctp_flow_prepare_output(                                             key, devB)                                           if (!key-\u003edev)  // still NULL                                           mctp_dev_set_key(devB, key)                                             mctp_dev_hold(devB)                                             key-\u003edev = devB     mctp_dev_set_key(devA, key)       mctp_dev_hold(devA)       key-\u003edev = devA   // overwrites devB  Now both devA and devB references were acquired, but only the final key-\u003edev value is tracked for release. One reference can be lost, causing a resource leak as mctp_dev_release_key() would only decrease the reference on one dev.  Fix by taking key-\u003elock around the key-\u003edev check and mctp_dev_set_key() call.",
  "id": "DEBIAN-CVE-2026-43455",
  "modified": "2026-09-14T16:47:45.881067488Z",
  "published": "2026-05-08T15:16:58.263Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-43455"
    }
  ],
  "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-43455"
  ]
}