In the Linux kernel, the following vulnerability has been resolved: nvme: remove stale namespaces…

Why it is Amber

• CVSS 7.5 high
• Remotely exploitable without logging in
• On your watchlist: linux kernel

References

• https://git.kernel.org/stable/c/4ed7f3d7d435bf5b63da2814dc9270f5ba896011
• https://git.kernel.org/stable/c/52200fc41a79da430ccf7c126ed837535b087ea2
• https://git.kernel.org/stable/c/c84ad7407fb16b92d9b7a649cc304a9cf3757897
• https://git.kernel.org/stable/c/e6a94b2c4c80a38002346ce915a9b9a3d478a3e6
• https://git.kernel.org/stable/c/f56b2bb4b18b017b056c4c17c66b2c4c54bf6ee4

Original 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.