{
  "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 policy smq: fix missing locks in invalidating cache blocks  In passthrough mode, the policy invalidate_mapping operation is called simultaneously from multiple workers, thus it should be protected by a lock. Otherwise, we might end up with data races on the allocated blocks counter, or even use-after-free issues with internal data structures when doing concurrent writes.  Note that the existing FIXME in smq_invalidate_mapping() doesn't affect passthrough mode since migration tasks don't exist there, but would need attention if supporting fast device shrinking via suspend/resume without target reloading.  Reproduce steps:  1. Create a cache device consisting of 1024 cache entries  dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" 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 262144 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\"  2. Populate the cache, and record the number of cached blocks  fio --name=populate --filename=/dev/mapper/cache --rw=randwrite --bs=4k \\ --size=64m --direct=1 nr_cached=$(dmsetup status cache | awk '{split($7, a, \"/\"); print a[1]}')  3. Reload the cache into passthrough mode  dmsetup suspend cache dmsetup reload cache --table \"0 262144 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0\" dmsetup resume cache  4. Write to the passthrough cache. By setting multiple jobs with I/O    size equal to the cache block size, cache blocks are invalidated    concurrently from different workers.  fio --filename=/dev/mapper/cache --name=test --rw=randwrite --bs=64k \\ --direct=1 --numjobs=2 --randrepeat=0 --size=64m  5. Check if demoted matches cached block count. These numbers should    match but may differ due to the data race.  nr_demoted=$(dmsetup status cache | awk '{print $12}') echo \"$nr_cached, $nr_demoted\"",
  "id": "DEBIAN-CVE-2026-53062",
  "modified": "2026-09-14T16:47:35.643888022Z",
  "published": "2026-06-24T17:17:19.030Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-53062"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-53062"
  ]
}