{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.176-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.94-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.10-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  dm cache metadata: fix memory leak on metadata abort retry  When failing to acquire the root_lock in dm_cache_metadata_abort because the block_manager is read-only, the temporary block_manager created outside the root_lock is not properly released, causing a memory leak.  Reproduce steps:  This can be reproduced by reloading a new table while the metadata is read-only. While the second call to dm_cache_metadata_abort is caused by lack of support for table preload in dm-cache, mentioned in commit 9b1cc9f251af (\"dm cache: share cache-metadata object across inactive and active DM tables\"), it exposes the memory leak in dm_cache_metadata_abort when the function is called multiple times. Specifically, dm-cache fails to sync the new cache object's mode during preresume, creating the reproducer condition.  This issue could also occur through concurrent metadata_operation_failed calls due to races in cache mode updates, but the table preload scenario below provides a reliable reproducer.  1. Create a cache device with some faulty trailing metadata blocks  dmsetup create cmeta \u003c\u003cEOF 0 200 linear /dev/sdc 0 200 7992 error EOF dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 262144 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 131072 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 1 writethrough smq 0\"  2. Suspend and resume the cache to start a new metadata transaction and    trigger metadata io errors on the next metadata commit.  dmsetup suspend cache dmsetup resume cache  3. Write to the cache device to update metadata  fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \\ --randrepeat=0 --direct=1 --size 64k  4. Preload the same table  dmsetup reload cache --table \"$(dmsetup table cache)\"  5. Resume the new table. This triggers the memory leak.  dmsetup suspend cache dmsetup resume cache  kmemleak logs:  \u003csnip\u003e unreferenced object 0xffff8880080c2010 (size 16):   comm \"dmsetup\", pid 132, jiffies 4294982580   hex dump (first 16 bytes):     00 38 b9 07 80 88 ff ff 6a 6b 6b 6b 6b 6b 6b a5 ...   backtrace (crc 3118f31c):     kmemleak_alloc+0x28/0x40     __kmalloc_cache_noprof+0x3d9/0x510     dm_block_manager_create+0x51/0x140     dm_cache_metadata_abort+0x85/0x320     metadata_operation_failed+0x103/0x1e0     cache_preresume+0xacd/0xe70     dm_table_resume_targets+0xd3/0x320     __dm_resume+0x1b/0xf0     dm_resume+0x127/0x170 \u003csnip\u003e",
  "id": "DEBIAN-CVE-2026-53060",
  "modified": "2026-09-14T16:47:36.071505287Z",
  "published": "2026-06-24T17:17:18.717Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-53060"
    }
  ],
  "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-53060"
  ]
}