s2
--:--:--UTC

Searching APEX

Starting…

  1. ○ Searching Threats, IOCs & Threat Intelligence locally
  2. ○ Querying external providers
  3. ○ Asking AI Forensic Validator
  4. ○ Creating new entry from validated hit

0s elapsed

CVE-2026-98056

📛 CVE Title

nvme: remove stale namespaces by NSID range during scan

Description

In the Linux kernel, the following vulnerability has been resolved: nvme: remove stale namespaces by NSID range during scan nvme_scan_ns_list() drops the stale namespaces in each gap in the reported NSID list one NSID at a time. Every iteration calls nvme_find_get_ns() to look the namespace up and removes it if it is present. The loop runs once per NSID in the gap rather than once per namespace actually present. NSIDs are 32-bit, so a target with a sparse NSID space can make a single gap spin the loop billions of times with nothing to remove. watchdog: BUG: soft lockup - CPU#4 stuck for 26s! Workqueue: nvme-wq nvme_scan_work [nvme_core] RIP: 0010:__srcu_read_unlock+0xb/0x20 Call Trace: nvme_find_get_ns+0x7d/0xb0 [nvme_core] nvme_scan_ns_list+0xe8/0x280 [nvme_core] nvme_scan_work+0x18a/0x280 [nvme_core] process_one_work+0x197/0x380 worker_thread+0x2fe/0x410 kthread+0xe0/0x100 Rename nvme_remove_invalid_namespaces() to nvme_remove_nsid_range() and give it an open (start, end) NSID range. ctrl->namespaces is sorted by NSID, so the whole gap is dropped in a single walk that stops once end is reached. This bounds the work by the namespaces that are present instead of by the size of the gap.

Overview

State
PUBLISHED
Assigner (CNA)
Linux
CVSS severity
HIGH
CVSS score
CVSS 7.5 / 10 7.5 7.5 / 10
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Effective score
7.5 / 10 HIGH source: CNA overview
CWE(s)
—
Reserved
2026-09-25
Published
2026-09-25 10:24 UTC
Last updated
2026-09-25 14:41 UTC
Source
https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/98xxx/CVE-2026-98056.json
Linked Threat
CVE-2026-98056 — nvme: remove stale namespaces by NSID range during scan

NVD triage scoring NVD CVE 2.0

Layer NVD adds on top of the CNA's CVE record — published / last-modified timestamps, exploitability / impact subscores, and the FIRST.org EPSS probability that this CVE will be exploited in the wild in the next 30 days.

NVD published
2026-09-25 11:17:34 UTC
NVD last modified
2026-09-25 15:18:05 UTC
NVD CVSS v3.1
CVSS 7.5 / 10 7.5 7.5 / 10 HIGH source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
NVD CVSS vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Exploitability subscore
3.9 / 10
Impact subscore
3.6 / 10

NVD / KEV / EPSS data refreshed 2026-09-26 04:24 UTC. Re-run the 🛰 Backfill from NVD button above to refresh.

Affected products (2)

VendorProductVersionsPlatforms
Linux Linux 540c801c65eb58e05e0ca38b6fd644a83d7e2b33 (affected), 540c801c65eb58e05e0ca38b6fd644a83d7e2b33 (affected), 540c801c65eb58e05e0ca38b6fd644a83d7e2b33 (affected), 540c801c65eb58e05e0ca38b6fd644a83d7e2b33 (affected) —
Linux Linux 4.5 (affected), 0 (unaffected), 6.12.111 (unaffected), 6.18.53 (unaffected), 7.2.7 (unaffected), 7.3-rc2 (unaffected) —

Vendor references (4)

References embedded in the original CVE record by the assigning CNA.

Web references (0)

DuckDuckGo results ranked by threat-intel / vendor advisory domains. Generated by the 🔎 Find references (web) button above — same flow as the Remediations search.

No web references attached yet.

NVD-tagged references (4)

Reference list NVD curates from the CNA record, vendor advisories, and third-party reports. The tag chips below are NVD's analyst-assigned categories.

AI Forensic Analysis

Only Available for Registered Users. Sign in to view.

Raw JSON

The full cvelistV5 record. Download as CVE-2026-98056.json.

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/nvme/host/core.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "c84ad7407fb16b92d9b7a649cc304a9cf3757897",
              "status": "affected",
              "version": "540c801c65eb58e05e0ca38b6fd644a83d7e2b33",
              "versionType": "git"
            },
            {
              "lessThan": "f56b2bb4b18b017b056c4c17c66b2c4c54bf6ee4",
              "status": "affected",
              "version": "540c801c65eb58e05e0ca38b6fd644a83d7e2b33",
              "versionType": "git"
            },
            {
              "lessThan": "52200fc41a79da430ccf7c126ed837535b087ea2",
              "status": "affected",
              "version": "540c801c65eb58e05e0ca38b6fd644a83d7e2b33",
              "versionType": "git"
            },
            {
              "lessThan": "4ed7f3d7d435bf5b63da2814dc9270f5ba896011",
              "status": "affected",
              "version": "540c801c65eb58e05e0ca38b6fd644a83d7e2b33",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/nvme/host/core.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.5"
            },
            {
              "lessThan": "4.5",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.111",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.53",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.7",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3-rc2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.111",
                  "versionStartIncluding": "4.5",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.53",
                  "versionStartIncluding": "4.5",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.7",
                  "versionStartIncluding": "4.5",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3-rc2",
                  "versionStartIncluding": "4.5",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme: remove stale namespaces by NSID range during scan\n\nnvme_scan_ns_list() drops the stale namespaces in each gap in the\nreported NSID list one NSID at a time. Every iteration calls\nnvme_find_get_ns() to look the namespace up and removes it if it is\npresent. The loop runs once per NSID in the gap rather than once per\nnamespace actually present.\n\nNSIDs are 32-bit, so a target with a sparse NSID space can make a\nsingle gap spin the loop billions of times with nothing to remove.\n\n  watchdog: BUG: soft lockup - CPU#4 stuck for 26s!\n  Workqueue: nvme-wq nvme_scan_work [nvme_core]\n  RIP: 0010:__srcu_read_unlock+0xb/0x20\n  Call Trace:\n   nvme_find_get_ns+0x7d/0xb0 [nvme_core]\n   nvme_scan_ns_list+0xe8/0x280 [nvme_core]\n   nvme_scan_work+0x18a/0x280 [nvme_core]\n   process_one_work+0x197/0x380\n   worker_thread+0x2fe/0x410\n   kthread+0xe0/0x100\n\nRename nvme_remove_invalid_namespaces() to nvme_remove_nsid_range()\nand give it an open (start, end) NSID range. ctrl->namespaces is\nsorted by NSID, so the whole gap is dropped in a single walk that\nstops once end is reached. This bounds the work by the namespaces\nthat are present instead of by the size of the gap."
        }
      ],
      "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 gap is taken from the NSID list in the controller's Identify Active Namespace List (CNS 02h) reply. Over NVMe/TCP a remote target writes that reply, and nvme_scan_ns_list() uses it without checks. A list such as {1, 0xFFFFFFFE} makes the 'while (++prev < nsid) nvme_ns_remove_by_nsid()' loop run about 4 billion times.\nAC:L - The target decides the NSID list, so the gap size is fully under its control and the spin happens every time. The target can also restart it on demand by sending a Namespace Attribute Changed AEN, which nvme_handle_aen_notice() turns into nvme_queue_scan().\nPR:N - No host credentials are needed. The data is the target's own Identify reply, which nvme_scan_work() reads automatically whenever the controller goes live or an AEN arrives.\nUI:N - Once the host is connected, the target sets off the scan itself (at connect or via its own AEN). No user on the host has to do anything.\nS:U - The damage stays inside the host kernel's NVMe core scan worker. No VM, IOMMU or sandbox boundary is crossed.\nC:N - The loop only looks up and removes namespaces with nvme_find_get_ns() and nvme_ns_remove(). Nothing is read out of bounds and no memory is disclosed.\nI:N - No memory is corrupted. The fix only bounds how much work the stale-namespace removal does, and the old code removed the right namespaces, just far too slowly.\nA:H - nvme_scan_work pins a CPU for about 2^32 SRCU lookups with no cond_resched(), which causes a soft lockup (a panic if softlockup_panic is set) while holding ctrl->scan_lock. Repeated AENs keep it going, which stalls namespace management and controller teardown."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-25T14:41:59.133Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/c84ad7407fb16b92d9b7a649cc304a9cf3757897"
        },
        {
          "url": "https://git.kernel.org/stable/c/f56b2bb4b18b017b056c4c17c66b2c4c54bf6ee4"
        },
        {
          "url": "https://git.kernel.org/stable/c/52200fc41a79da430ccf7c126ed837535b087ea2"
        },
        {
          "url": "https://git.kernel.org/stable/c/4ed7f3d7d435bf5b63da2814dc9270f5ba896011"
        }
      ],
      "title": "nvme: remove stale namespaces by NSID range during scan",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-98056",
    "datePublished": "2026-09-25T10:24:02.919Z",
    "dateReserved": "2026-09-25T10:19:56.072Z",
    "dateUpdated": "2026-09-25T14:41:59.133Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}