GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux nvme: sparse NSID gaps make namespace scan iterate billions of times, causing soft lockup

CVSS 7.5CVE-2026-98056Kernel, userspace & hypervisorcurated

Impact

nvme_scan_ns_list() dropped stale namespaces one NSID at a time across each gap in the reported NSID list, so the loop ran once per NSID in the gap rather than once per namespace actually present. NSIDs are 32-bit, so a target advertising a sparse NSID space makes a single gap spin billions of iterations, producing a soft lockup in nvme_scan_work on the nvme workqueue. This matters most where the NVMe target is not fully trusted or not fully controlled - NVMe-over-Fabrics storage serving GPU nodes - because a target-side NSID layout stalls a CPU on the host and hangs namespace scanning. Impact is availability only; the fix bounds the walk by the namespaces present rather than by the size of the gap.

Who can reach it

A NVMe target (local or over fabrics) that reports a sparse NSID list to the host. No host-side authentication or local access is required, but the attacker must control or influence the target's namespace reporting.

What to do

Take the stable kernel update carrying the nvme_remove_nsid_range() rework (four stable commits referenced). Kernel update and reboot per host; there is no configuration-level mitigation other than not attaching untrusted NVMe targets.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.