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.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS Score: 7.5
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.
AC: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().
PR: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.
UI: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.
S:U - The damage stays inside the host kernel's NVMe core scan worker. No VM, IOMMU or sandbox boundary is crossed.
C: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.
I: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.
A: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.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
None |
| Privileges Required |
None |
Integrity Impact |
None |
| User Interaction |
None |
Availability Impact |
High |
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.
AC: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().
PR: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.
UI: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.
S:U - The damage stays inside the host kernel's NVMe core scan worker. No VM, IOMMU or sandbox boundary is crossed.
C: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.
I: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.
A: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.
CVSS 3.1