From: Max Reitz <mreitz@redhat.com>
To: Klaus Jensen <its@irrelevant.dk>, qemu-devel@nongnu.org
Cc: Keith Busch <kbusch@kernel.org>, Kevin Wolf <kwolf@redhat.com>,
qemu-block@nongnu.org, Klaus Jensen <k.jensen@samsung.com>
Subject: Re: [PATCH 2/2] hw/block/nvme: fix resource leak in nvme_format_ns
Date: Mon, 22 Mar 2021 11:02:21 +0100 [thread overview]
Message-ID: <75eb366b-32d9-ba67-971b-e5993f5ae192@redhat.com> (raw)
In-Reply-To: <20210322061951.186748-3-its@irrelevant.dk>
On 22.03.21 07:19, Klaus Jensen wrote:
> From: Klaus Jensen <k.jensen@samsung.com>
>
> In nvme_format_ns(), if the namespace is of zero size (which might be
> useless, but not invalid), the `count` variable will leak. Fix this by
> returning early in that case.
When looking at the Coverity report, something else caught my eye: As
far as I’m aware, blk_aio_pwrite_zeroes() may invoke the CB before
returning (if blk_do_pwritev_part() returns without yielding). I don’t
think that will happen with real hardware (who knows, though), but it
should be possible to see with the null-co block driver.
nvme_format_ns() doesn’t quite look like it takes that into account.
For example, because *count starts at 1 and is decremented after the
while (len) loop, all nvme_aio_format_cb() invocations (if they are
invoked before their blk_aio_pwrite_zeroes() returns) will see
*count == 2, and thus not free it, or call nvme_enqueue_req_completion().
I don’t know whether the latter is problematic, but not freeing `count`
doesn’t seem right. Perhaps this could be addressed by adding a
condition to the `(*count)--` to see whether `(*count)-- == 1` (or
rather `--(*count) == 0`), which would indicate that there are no AIO
functions still in flight?
Max
> Reported-by: Coverity (CID 1451082)
> Fixes: dc04d25e2f3f ("hw/block/nvme: add support for the format nvm command")
> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
> ---
> hw/block/nvme.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/hw/block/nvme.c b/hw/block/nvme.c
> index 6842b01ab58b..dad275971a84 100644
> --- a/hw/block/nvme.c
> +++ b/hw/block/nvme.c
> @@ -4984,6 +4984,11 @@ static uint16_t nvme_format_ns(NvmeCtrl *n, NvmeNamespace *ns, uint8_t lbaf,
> ns->status = NVME_FORMAT_IN_PROGRESS;
>
> len = ns->size;
> +
> + if (!len) {
> + return NVME_SUCCESS;
> + }
> +
> offset = 0;
>
> count = g_new(int, 1);
>
next prev parent reply other threads:[~2021-03-22 10:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 6:19 [PATCH 0/2] hw/block/nvme: coverity fixes Klaus Jensen
2021-03-22 6:19 ` [PATCH 1/2] hw/block/nvme: fix resource leak in nvme_dif_rw Klaus Jensen
2021-03-22 6:19 ` [PATCH 2/2] hw/block/nvme: fix resource leak in nvme_format_ns Klaus Jensen
2021-03-22 10:02 ` Max Reitz [this message]
2021-03-22 10:48 ` Klaus Jensen
2021-03-22 11:06 ` Max Reitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=75eb366b-32d9-ba67-971b-e5993f5ae192@redhat.com \
--to=mreitz@redhat.com \
--cc=its@irrelevant.dk \
--cc=k.jensen@samsung.com \
--cc=kbusch@kernel.org \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.