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 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.