From: Niklas Cassel <cassel@kernel.org>
To: Rihyeon Kim <rihyeon8648@gmail.com>
Cc: justin.tee@broadcom.com, nareshgottumukkala83@gmail.com,
paul.ely@broadcom.com, kbusch@kernel.org, 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: Mon, 17 Aug 2026 17:10:23 +0200 [thread overview]
Message-ID: <aoMkX_davK7TWlaj@ryzen> (raw)
In-Reply-To: <20260817061815.154794-1-rihyeon8648@gmail.com>
On Mon, Aug 17, 2026 at 03:18:15PM +0900, Rihyeon Kim wrote:
> Hello,
>
> Thanks for the explanation, and for picking this up.
>
> My testing of v1 and v2 never reached this case. The syzbot config has
> "# CONFIG_NVME_HOST_AUTH is not set", and I was not aware that the
> dhchap option tokens are compiled out when it is disabled. A connect
> string containing dhchap_secret= is simply rejected, so every run I did
> tore down with ctrl->dhchap_ctxs NULL, and there was no path that
> dereferenced ctrl->opts.
>
> I rebuilt with CONFIG_NVME_HOST_AUTH=y and swept fail-nth 1..200 over a
> connect write containing dhchap_secret=. You are right:
>
> clearing opts at out_put_ctrl: dies at attempt 20
> this patch 200/200, with 35 of the injections
> landing in nvme_add_ctrl()
>
> Oops: general protection fault, probably for non-canonical address
> 0xdffffc0000000008
> KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047]
> RIP: 0010:nvme_auth_free+0x99/0x450
> nvme_free_ctrl+0x231/0x6c0
>
> The injection for that attempt landed in kobj_map() under cdev_add(), so
> this is the nvme_add_ctrl() failure path. ctrl_max_dhchaps() then
> dereferences ctrl->opts at offset 0x40. Clearing the pointer really does
> just trade the double free for this NULL pointer dereference. Good catch.
Thanks a lot for verifying that the Sashiko comment about the NULL pointer
dereference in nvme_auth_free() can actually happen, and was not only
theoretical.
>
> Your version also addresses the two things I was unsure about in my
> earlier mail: fail_unlist: covers the two exit paths after
> list_add_tail(), and checking list_empty() while holding the lock keeps
> ida_free(), put_device(), and nvme_fc_rport_put() on the unlisted path.
>
> Dropping my v2 in favour of this one.
>
> Tested-by: Rihyeon Kim <rihyeon8648@gmail.com>
It seems like Keith did prefer your patch, but as you said, your patch does
not avoid a NULL pointer dereference in nvme_auth_free().
My patch should also avoid a potential sysfs NULL pointer dereference as
reported by Sashiko:
https://sashiko.dev/#/patchset/20260811125310.165487-1-rihyeon8648%40gmail.com
which is currently also only possible for fc.c, because of the
'ctrl->ctrl.opts = NULL;' hack.
Personally, I prefer this patch, since it makes fc.c more similar to rdma.c,
tcp.c, and loop.c, by checking if the controller is on the linked list or not,
rather than setting 'ctrl->ctrl.opts = NULL;' before the teardown is even done.
I agree that this patch adds more code than what we ideally would have wanted,
but I don't see any other way (other than completely refactoring the ownership
model of the controller options - which would require much bigger changes -
and would most likely require changes to both fabrics.c + all the different
transport drivers).
Kind regards,
Niklas
next prev parent reply other threads:[~2026-08-17 15:10 UTC|newest]
Thread overview: 15+ 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 [this message]
2026-08-19 15:28 ` Keith Busch
2026-08-19 18:32 ` 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=aoMkX_davK7TWlaj@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-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