Re: [PATCH] nvme-rdma: fix NULL queue->ctrl dereference on reconnect

[Nilay Shroff <nilay@linux.ibm.com>]

On 10/29/26 7:48 PM, Christian Aurich Zanettini Martins wrote:
> On Thu, Oct 29, 2026 at 03:05:21AM -0300, Christian Aurich Zanettini Martins wrote:
>>   static void nvme_rdma_free_ctrl(struct nvme_ctrl *nctrl)
>>   {
>>   	struct nvme_rdma_ctrl *ctrl = to_rdma_ctrl(nctrl);
>> +	int i, nr_queues = NVME_RDMA_OPT_NR_QUEUES(nctrl->opts);
> 
> Please drop this one, I'll send a v2. Thanks for the reviews, Nilay
> and Christoph.
> 
> When creating the controller fails, nvmf_create_ctrl() frees opts right
> after nvme_put_ctrl(), but that put is not always the last one. With
> CONFIG_DEBUG_KOBJECT_RELEASE, KASAN reports a use-after-free here on
> every failed connect.
> 
> v2 only moves queue->ctrl and leaves queue_lock where it is.

Ah, so in v2, we would only move the initialization of queue->ctrl while
leaving queue->queue_lock unchanged. This avoids tying the lifetime of
queue->queue_lock to the rdma controller and looks correct.

However, I think a similar issue could arise in the NVMe/TCP implementation
due to the recent changes in commit 2eeeaa9c1ff0 ("nvme-tcp: Validate the
queue state under the queue lock in the address attribute"). We should
probably address those changes as well.

Unlike NVMe/RDMA, NVMe/TCP needs to tie the lifetime of queue->queue_lock
to that of the tcp controller. Therefore, we may need to introduce a separate
ctrl->allocated_queue_count, initialized with the number of queues allocated
at connect time. We could then use ctrl->allocated_queue_count in
nvme_tcp_free_ctrl() to destroy the controller-owned queue objects, rather
than accessing nctrl->opts to determine nr_queues.

Thanks,
--Nilay