[PATCH] nvme: Fix potential gendisk leak in nvme_alloc_ns

[PATCH] nvme: Fix potential gendisk leak in nvme_alloc_ns

[Smith, Kyle]

Multiple BUGs were seen after the following sequence:
1) ctrl A in subsys A allocs ns nvmeAcAn1 and ns_head nvmeAn1 and sets
   both as live
2) ctrl B in subsys A allocs ns nvmeAcBn1 under ns_head nvmeAn1, but is
   interrupted or stalled between nvme_init_ns_head and healthy return
3) the namespace is removed from subsystem, triggering rescan
4) nvmeAcAn1 completes nvme_ns_remove
5) nvmeAcBn1 allocation returns through an error pathway in nvme_alloc_ns

In this sequence, when nvmeAcBn1 returns, it is the last path and has the
responsibility of shutting down the live ns_head, but does not call
nvme_mpath_shutdown_disk. Failure to call nvme_mpath_shutdown_disk leaves
the gendisk active in sysfs/devfs while components around it are freed.
The result is that a new nvme_ns_head with the same namespace number
cannot be created in sysfs and freed memory can be accessed through
remaining userspace files. Most observed panics were seen from paths
utilizing nvme_find_path, such as nuse_show or blkdev_ioctl, though
occasionally corruption of the dpm list was detected as well.

Fix here is to simply keep ns_head cleanup the same as nvme_ns_remove.
This ensures we don't break delayed removal and that we clean up the
gendisk when appropriate.

Signed-off-by: Kyle Smith <kyles@hpe.com>
---
In our setup, this was enabled by a time out of the namespace identify
command sent from nvme_update_ns_info_block in conjunction with a
faulty target device, though it should be possible with smaller
windows if interrupts catch things the wrong way.

 drivers/nvme/host/core.c | 16 ++++------------
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index a7a4d09644c1..682b51118b30 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -4364,24 +4364,16 @@ static void nvme_alloc_ns(struct nvme_ctrl *ctrl, struct nvme_ns_info *info)
 	mutex_lock(&ctrl->subsys->lock);
 	list_del_rcu(&ns->siblings);
 	if (list_empty(&ns->head->list)) {
-		list_del_init(&ns->head->entry);
-		/*
-		 * If multipath is not configured, we still create a namespace
-		 * head (nshead), but head->disk is not initialized in that
-		 * case.  As a result, only a single reference to nshead is held
-		 * (via kref_init()) when it is created. Therefore, ensure that
-		 * we do not release the reference to nshead twice if head->disk
-		 * is not present.
-		 */
-		if (ns->head->disk)
-			last_path = true;
+		if (!nvme_mpath_queue_if_no_path(ns->head))
+			list_del_init(&ns->head->entry);
+		last_path = true;
 	}
 	mutex_unlock(&ctrl->subsys->lock);
 
 	/* guarantee not available in head->list */
 	synchronize_srcu(&ns->head->srcu);
 	if (last_path)
-		nvme_put_ns_head(ns->head);
+		nvme_mpath_remove_disk(ns->head);
 	nvme_put_ns_head(ns->head);
  out_cleanup_disk:
 	put_disk(disk);

Re: [PATCH] nvme: Fix potential gendisk leak in nvme_alloc_ns

[hch]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH] nvme: Fix potential gendisk leak in nvme_alloc_ns

[Keith Busch]

On Thu, 5 Nov 2026 21:54:38 +0000, Smith, Kyle wrote:
> Multiple BUGs were seen after the following sequence:
> 1) ctrl A in subsys A allocs ns nvmeAcAn1 and ns_head nvmeAn1 and sets
>    both as live
> 2) ctrl B in subsys A allocs ns nvmeAcBn1 under ns_head nvmeAn1, but is
>    interrupted or stalled between nvme_init_ns_head and healthy return
> 3) the namespace is removed from subsystem, triggering rescan
> 4) nvmeAcAn1 completes nvme_ns_remove
> 5) nvmeAcBn1 allocation returns through an error pathway in nvme_alloc_ns
> 
> [...]

Thanks, applied to nvme-7.4.

[1/1] nvme: Fix potential gendisk leak in nvme_alloc_ns
      commit: 1e1d36e7610fc2c2c425ea246caf8ea0380d5fd6
--
Keith Busch <kbusch@kernel.org>