Re: [PATCH] nvmet-fc: fix invalid free in LS IOD error path

["Maurizio Lombardi" <mlombard@arkamax.eu>]

On Wed Jul 29, 2026 at 1:02 PM CEST, Jiang HongHui wrote:
> nvmet_fc_alloc_ls_iodlist() advances iod while initializing the LS IOD
> array. If an rqstbuf allocation or response buffer DMA mapping fails,
> the unwind loop decrements iod past the start of the array. The final
> kfree(iod) therefore frees an address before the allocated object.
>
> This can be reproduced with nvme-fcloop and failslab by setting
> fail-nth to 6 before creating a target port. KASAN reports:
>
>   BUG: KASAN: invalid-free in nvmet_fc_register_targetport
>   Free of addr ffff88816cf8ff48 by task nvmet_fail_nth/9552
>
> Free the original allocation base stored in tgtport->iod instead. With
> this fix applied, the same sysfs write with fail-nth=6 returns -ENOMEM
> without any KASAN report.
>
> Fixes: c53432030d86 ("nvme-fabrics: Add target support for FC transport")
> Cc: stable@vger.kernel.org
> Assisted-by: Codex:gpt-5
> Signed-off-by: Jiang HongHui <jiang_hh2019@163.com>
> ---
> Tested on v7.2-rc5 with CONFIG_NVME_TARGET_FCLOOP=m, CONFIG_KASAN=y,
> CONFIG_FAULT_INJECTION=y and CONFIG_FAILSLAB=y.
>
> Before the fix, faddr2line resolved the fail-nth=6 injection to the
> rqstbuf kzalloc() at drivers/nvme/target/fc.c:542, and KASAN reported
> an invalid free. After the fix, the same injection resolved to the same
> allocation, the sysfs write returned -ENOMEM, fail-nth read back as 0,
> and dmesg contained no KASAN, invalid-free, BAD_PAGE or Oops reports.
>
>  drivers/nvme/target/fc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/nvme/target/fc.c b/drivers/nvme/target/fc.c
> index d16170755..1b557775e 100644
> --- a/drivers/nvme/target/fc.c
> +++ b/drivers/nvme/target/fc.c
> @@ -566,7 +566,7 @@ nvmet_fc_alloc_ls_iodlist(struct nvmet_fc_tgtport *tgtport)
>  		list_del(&iod->ls_rcv_list);
>  	}
>  
> -	kfree(iod);
> +	kfree(tgtport->iod);
>  
>  	return -EFAULT;
>  }
>
> base-commit: f5098b6bae761e346ebcd9da7f95622c04733cff

Reviewed-by: Maurizio Lombardi <mlombard@redhat.com>