[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac062d49-05bd-4615-ac38-4a463d533917@suse.de>
Date: Tue, 19 Dec 2023 12:41:50 +0100
From: Hannes Reinecke <hare@...e.de>
To: Daniel Wagner <dwagner@...e.de>, linux-nvme@...ts.infradead.org
Cc: linux-kernel@...r.kernel.org, Christoph Hellwig <hch@....de>,
Sagi Grimberg <sagi@...mberg.me>, Keith Busch <kbusch@...nel.org>,
James Smart <james.smart@...adcom.com>
Subject: Re: [PATCH v3 14/16] nvmet-fc: free hostport after release reference
to tgtport
On 12/18/23 16:31, Daniel Wagner wrote:
> Give the ref back before destroying the hostport object to prevent a
> potential UAF.
>
> Signed-off-by: Daniel Wagner <dwagner@...e.de>
> ---
> 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 663c51c9fe53..23d8779dc221 100644
> --- a/drivers/nvme/target/fc.c
> +++ b/drivers/nvme/target/fc.c
> @@ -986,8 +986,8 @@ nvmet_fc_hostport_free(struct kref *ref)
> spin_unlock_irqrestore(&tgtport->lock, flags);
> if (tgtport->ops->host_release && hostport->invalid)
> tgtport->ops->host_release(hostport->hosthandle);
> - kfree(hostport);
> nvmet_fc_tgtport_put(tgtport);
> + kfree(hostport);
> }
>
> static void
That, I guess, needs some more explanation.
It's not immediately obvious why a 'put' on the targetport would
have implications on the hostport. But when it does wouldn't it
be more sensible to free up the reference to the hostport when the
final 'put' on the target port happens?
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@...e.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Ivo Totev, Andrew McDonald,
Werner Knoblich
Powered by blists - more mailing lists