{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.101-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.6-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux-6.12"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.101-1~deb12u1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  mtd: fix double free and WARN_ON in add_mtd_device() error paths  When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free.  Additionally, release_mtd_partition() hits WARN_ON(!list_empty( \u0026mtd-\u003epart.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path.  Fix this by overriding dev-\u003etype and dev-\u003erelease before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called.  The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract.  The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -\u003e mtd_device_release() -\u003e device_unregister() with dev-\u003etype still set to \u0026mtd_devtype, so mtd_release() -\u003e release_mtd_partition() continues to work correctly for the regular removal case.",
  "id": "DEBIAN-CVE-2026-68416",
  "modified": "2026-09-14T16:47:50.710087763Z",
  "published": "2026-08-10T13:20:35.383Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-68416"
    }
  ],
  "upstream": [
    "CVE-2026-68416"
  ]
}