Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
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.


  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