[PATCH] nvmet-fc: skip port entry rebinding if already bound to a target port

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] nvme-target/fc: reference count leak of tgtport on rebind conflict
--

commit 69be6b42e2f6eef3ebd6d221309e5ccb64969922
Author: Nguyen Duy Nhat Anh <neganhat at gmail.com>

nvmet-fc: skip port entry rebinding if already bound to a target port

This commit adds a check to avoid clobbering existing target port
assignments during rebinding. It prevents multiple concurrent or duplicate
target port registrations from overwriting an already-assigned port entry.

Closes: https://syzkaller.appspot.com/bug?extid=be62d4b375542ecebd17

> diff --git a/drivers/nvme/target/fc.c b/drivers/nvme/target/fc.c
> index eecdffefa24fa..ac3194497a1e0 100644
> --- a/drivers/nvme/target/fc.c
> +++ b/drivers/nvme/target/fc.c
> @@ -1324,7 +1324,9 @@ nvmet_fc_portentry_rebind_tgt(struct nvmet_fc_tgtport *tgtport)
>  			if (!nvmet_fc_tgtport_get(tgtport))
>  				continue;
>  
> -			WARN_ON(pe->tgtport);
> +			if (pe->tgtport)
> +				continue;
> +

[Severity: Medium]
Does this code leak the reference count on the target port?

The commit message states the intent to check for an existing assignment
before acquiring the reference count, but the check is placed immediately
after nvmet_fc_tgtport_get() has already incremented the reference. 

If pe->tgtport is already set, the continue statement will move to the next
iteration without releasing the reference acquired by nvmet_fc_tgtport_get(),
permanently leaking it and preventing the target port from being freed upon
unregistration.

>  			tgtport->pe = pe;
>  			pe->tgtport = tgtport;
>  			break;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016155415.10521-1-neganhat@gmail.com?part=1