CVE-2023-54227 (GCVE-0-2023-54227)
Vulnerability from cvelistv5
Published
2025-12-30 12:11
Modified
2026-08-05 09:18
Severity ?
7.5 (High) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix tags leak when shrink nr_hw_queues Although we don't need to realloc set->tags[] when shrink nr_hw_queues, we need to free them. Or these tags will be leaked. How to reproduce: 1. mount -t configfs configfs /mnt 2. modprobe null_blk nr_devices=0 submit_queues=8 3. mkdir /mnt/nullb/nullb0 4. echo 1 > /mnt/nullb/nullb0/power 5. echo 4 > /mnt/nullb/nullb0/submit_queues 6. rmdir /mnt/nullb/nullb0 In step 4, will alloc 9 tags (8 submit queues and 1 poll queue), then in step 5, new_nr_hw_queues = 5 (4 submit queues and 1 poll queue). At last in step 6, only these 5 tags are freed, the other 4 tags leaked.
References
Impacted products
Vendor Product Version
Linux Linux Version: a846a8e6c9a5949582c5a6a8bbc83a7d27fd891e
Version: a846a8e6c9a5949582c5a6a8bbc83a7d27fd891e
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "block/blk-mq.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "c0ef7493e68b8896806a2f598fcffbaa97333405",
              "status": "affected",
              "version": "a846a8e6c9a5949582c5a6a8bbc83a7d27fd891e",
              "versionType": "git"
            },
            {
              "lessThan": "e1dd7bc93029024af5688253b0c05181d6e01f8e",
              "status": "affected",
              "version": "a846a8e6c9a5949582c5a6a8bbc83a7d27fd891e",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "block/blk-mq.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.16"
            },
            {
              "lessThan": "5.16",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.5.*",
              "status": "unaffected",
              "version": "6.5.5",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.6",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.5.5",
                  "versionStartIncluding": "5.16",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6",
                  "versionStartIncluding": "5.16",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: fix tags leak when shrink nr_hw_queues\n\nAlthough we don\u0027t need to realloc set-\u003etags[] when shrink nr_hw_queues,\nwe need to free them. Or these tags will be leaked.\n\nHow to reproduce:\n1. mount -t configfs configfs /mnt\n2. modprobe null_blk nr_devices=0 submit_queues=8\n3. mkdir /mnt/nullb/nullb0\n4. echo 1 \u003e /mnt/nullb/nullb0/power\n5. echo 4 \u003e /mnt/nullb/nullb0/submit_queues\n6. rmdir /mnt/nullb/nullb0\n\nIn step 4, will alloc 9 tags (8 submit queues and 1 poll queue), then\nin step 5, new_nr_hw_queues = 5 (4 submit queues and 1 poll queue).\nAt last in step 6, only these 5 tags are freed, the other 4 tags leaked."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:N - The shrink is driven by remote-peer data on NVMe-oF hosts \u2014 `nvme_set_queue_count()` takes the I/O queue count verbatim from the target\u0027s Set Features completion and feeds it to `blk_mq_update_nr_hw_queues()` on every reconnect, with the tag set persisting across reconnects. A hostile/compromised target or on-path attacker on an unauthenticated NVMe/TCP fabric reaches the vulnerable code over the network.\nAC:L - The attacker fully controls the granted queue count in each Set Features response and can force reconnects at will by closing the transport connection, so each shrink\u2192grow cycle is triggered deterministically with no conditions outside the attacker\u0027s control.\nPR:N - The remote peer needs no credentials on the victim host; NVMe/TCP in the affected 5.16\u20136.5 range has no in-band authentication or TLS, and the queue-count negotiation happens automatically during controller reconnect.\nUI:N - Reconnect and queue renegotiation are fully automatic in the nvme fabrics keep-alive/reconnect path; no administrator or user action is needed at exploitation time.\nS:U - The leaked allocations and the resulting memory pressure are confined to the kernel of the affected host; no security authority boundary such as a VM or IOMMU domain is crossed.\nC:N - The leaked `blk_mq_tags` and request pages are simply never freed \u2014 they are not read, exposed, or transmitted anywhere, so no information is disclosed to the attacker.\nI:N - No out-of-bounds write, use-after-free, or type confusion occurs; the stale pointers are only dropped, leaving no primitive to modify kernel or user data.\nA:H - Because the regrow path memcpy\u0027s only the shrunken count and frees the old array, every shrink\u2192grow cycle permanently leaks a full per-queue request pool, making the leak unbounded and repeatable until kernel memory is exhausted and the system OOMs or hangs."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T09:18:13.008Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/c0ef7493e68b8896806a2f598fcffbaa97333405"
        },
        {
          "url": "https://git.kernel.org/stable/c/e1dd7bc93029024af5688253b0c05181d6e01f8e"
        }
      ],
      "title": "blk-mq: fix tags leak when shrink nr_hw_queues",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2023-54227",
    "datePublished": "2025-12-30T12:11:20.207Z",
    "dateReserved": "2025-12-30T12:06:44.502Z",
    "dateUpdated": "2026-08-05T09:18:13.008Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.