From: Keith Busch <kbusch@kernel.org>
To: Niklas Cassel <cassel@kernel.org>
Cc: Rihyeon Kim <rihyeon8648@gmail.com>,
justin.tee@broadcom.com, nareshgottumukkala83@gmail.com,
paul.ely@broadcom.com, axboe@kernel.dk, hch@lst.de,
sagi@grimberg.me, kch@nvidia.com, stable@vger.kernel.org,
syzbot+f58e57380a6083c4041d@syzkaller.appspotmail.com,
linux-nvme@lists.infradead.org
Subject: Re: [PATCH] nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails
Date: Fri, 21 Aug 2026 08:18:31 -0600 [thread overview]
Message-ID: <aoheN_L3iJNU3Ji6@kbusch-mbp> (raw)
In-Reply-To: <aohQ9NcuMtSqWvvd@ryzen>
On Fri, Aug 21, 2026 at 03:21:56PM +0200, Niklas Cassel wrote:
> On Thu, Aug 20, 2026 at 09:23:10AM -0600, Keith Busch wrote:
> > On Wed, Aug 19, 2026 at 08:32:33PM +0200, Niklas Cassel wrote:
> > >
> > > I am not following.
> > >
> > > The options is freed in two different places, depending on if the
> > > ops->create_ctrl(dev, opts) call in fabrics.c:nvmf_create_ctrl() was
> > > successful or not.
> >
> > Oh, not that path. You mentioned previously that ctrl->ops is
> > dereferenced in other places. I thought this means we can successfully
> > add the controller, which means the attributes are visible, but then
> > fail something else later that causes the opts to free. Since the
> > attribute was visible, something can open it before the device exporting
> > is torn down, and access it after the opts were freed.
>
> Sashiko flagged another NULL pointer defererence from the sysfs attributes:
>
> "While the sysfs attributes are still fully accessible, an unprivileged user
> could concurrently read an attribute like hostnqn, causing a NULL pointer
> dereference.":
> https://sashiko.dev/#/patchset/20260811125310.165487-1-rihyeon8648%40gmail.com
>
> This comment was on Rihyeon Kim's patch proposal.
>
> I assume that this is because the fc.c driver (both before and after
> Rihyeon patch) force set ctrl->ops = NULL before nvme_free_ctrl() was
> called, so a user reading the sysfs attributes at the same time as the
> controller was tearing down, could most likely crash the kernel.
> (Note that neither rdma.c,tcp.c,loop.c does this, so this problem does
> not exist for them.)
>
> sysfs_remove_link() is called before ctrl->ops->free_ctrl(ctrl);
When ops->create_ctrl() fails, the opts are freed from
nvmf_create_ctrl(). We can still fail ops->create_ctrl() after a
successful nvme_add_ctrl(), so the handle will be visible to user space
for a moment.
I think you're relying on nvme_fc_init_ctrl's nvme_put_ctrl() error case
to be the final reference, but it might not be if the character device
was created and someone opened it. If so then:
out_put_ctrl:
nvme_put_ctrl() -> refcount 1, NOT zero
So now when nvme_free_ctrl is called sometime after nvmf_create_ctrl()
freed the opts, the ctrl is pointing to freed memory.
next prev parent reply other threads:[~2026-08-21 14:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 14:38 [PATCH] nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails Niklas Cassel
2026-08-14 16:30 ` Keith Busch
2026-08-17 6:18 ` Rihyeon Kim
2026-08-17 15:10 ` Niklas Cassel
2026-08-19 15:28 ` Keith Busch
2026-08-19 18:32 ` Niklas Cassel
2026-08-20 15:23 ` Keith Busch
2026-08-21 13:21 ` Niklas Cassel
2026-08-21 14:18 ` Keith Busch [this message]
2026-08-21 14:35 ` Keith Busch
2026-08-21 14:56 ` Niklas Cassel
-- strict thread matches above, loose matches on Subject: below --
2026-08-11 2:06 [syzbot] [nvme?] KASAN: slab-use-after-free Read in nvmf_free_options syzbot
2026-08-11 12:53 ` [PATCH] nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails Rihyeon Kim
2026-08-11 13:10 ` Niklas Cassel
2026-08-12 10:55 ` Rihyeon Kim
2026-08-12 10:59 ` Rihyeon Kim
2026-08-12 14:26 ` Niklas Cassel
2026-08-12 14:30 ` Niklas Cassel
2026-08-11 15:29 ` Keith Busch
2026-08-12 10:55 ` Rihyeon Kim
2026-08-12 10:59 ` Rihyeon Kim
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=aoheN_L3iJNU3Ji6@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=axboe@kernel.dk \
--cc=cassel@kernel.org \
--cc=hch@lst.de \
--cc=justin.tee@broadcom.com \
--cc=kch@nvidia.com \
--cc=linux-nvme@lists.infradead.org \
--cc=nareshgottumukkala83@gmail.com \
--cc=paul.ely@broadcom.com \
--cc=rihyeon8648@gmail.com \
--cc=sagi@grimberg.me \
--cc=stable@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox