From: Niklas Cassel <cassel@kernel.org>
To: Rihyeon Kim <rihyeon8648@gmail.com>
Cc: kbusch@kernel.org, hch@lst.de, sagi@grimberg.me, axboe@kernel.dk,
justin.tee@broadcom.com, nareshgottumukkala83@gmail.com,
paul.ely@broadcom.com, kch@nvidia.com,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
syzbot+f58e57380a6083c4041d@syzkaller.appspotmail.com
Subject: Re: [PATCH v2] nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails
Date: Fri, 14 Aug 2026 16:43:57 +0200 [thread overview]
Message-ID: <an8prQiY-Vzxf8nh@ryzen> (raw)
In-Reply-To: <20260812122503.196828-1-rihyeon8648@gmail.com>
Hello Rihyeon,
On Wed, Aug 12, 2026 at 09:25:03PM +0900, Rihyeon Kim wrote:
> nvmf_create_ctrl() frees opts when ->create_ctrl() returns an error, so
> a transport must not free it on its own error paths. nvme_fc_ctrl_free()
> therefore only calls nvmf_free_options() while ctrl->ctrl.opts is still
> set, and nvme_fc_init_ctrl() clears that pointer before its last put.
>
> It only does so on the fail_ctrl: path. When nvme_add_ctrl() fails,
> nvme_fc_init_ctrl() jumps to out_put_ctrl: instead, so
> nvme_fc_ctrl_free() still sees ctrl->ctrl.opts set and frees opts, and
> nvmf_create_ctrl() frees it again.
>
> Reproduced with nvme-fcloop and failslab by failing the kvasprintf() in
> dev_set_name(), called from nvme_add_ctrl():
>
> BUG: KASAN: slab-use-after-free in nvmf_free_options+0x30/0x190
> nvmf_free_options+0x30/0x190 drivers/nvme/host/fabrics.c:1284
> nvmf_create_ctrl drivers/nvme/host/fabrics.c:1374 [inline]
> Freed by task 5534:
> nvme_fc_ctrl_free drivers/nvme/host/fc.c:2374 [inline]
> nvme_fc_init_ctrl+0xe17/0x1450 drivers/nvme/host/fc.c:3605
>
> Without KASAN, opts is freed twice.
>
> nvme-tcp and nvme-rdma reach the same error path, but their free_ctrl
> only frees opts once the controller is on the global list, so they are
> not affected.
>
> Move the clear down to out_put_ctrl:, which both error paths pass
> through. The same injection then returns -EIO without a report.
>
> Fixes: 1a9e218195a5 ("nvme: split device add from initialization")
> Cc: stable@vger.kernel.org
> Reported-by: syzbot+f58e57380a6083c4041d@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=f58e57380a6083c4041d
> Suggested-by: Keith Busch <kbusch@kernel.org>
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Rihyeon Kim <rihyeon8648@gmail.com>
> ---
I created an alternative fix that makes fc behave the same way as
tcp/rdma/loop, i.e. derive ownership from seeing if the ctrl is on
the list or not:
https://lore.kernel.org/linux-nvme/20260814143833.1953415-2-cassel@kernel.org/T/#u
This has the advantage of avoiding the NULL pointer dereferences in
nvme_auth_free() and when accessing the sysfs attributes during teardown,
as reported by Sashiko, as ctrl->ctrl.opts now stays valid for the whole
teardown.
Please review.
Kind regards,
Niklas
prev parent reply other threads:[~2026-08-14 14:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 12:25 [PATCH v2] nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails Rihyeon Kim
2026-08-14 14:43 ` Niklas Cassel [this message]
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=an8prQiY-Vzxf8nh@ryzen \
--to=cassel@kernel.org \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=justin.tee@broadcom.com \
--cc=kbusch@kernel.org \
--cc=kch@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=nareshgottumukkala83@gmail.com \
--cc=paul.ely@broadcom.com \
--cc=rihyeon8648@gmail.com \
--cc=sagi@grimberg.me \
--cc=syzbot+f58e57380a6083c4041d@syzkaller.appspotmail.com \
/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.