From: Breno Leitao <leitao@debian.org>
To: Slawomir Stepien <sst@poczta.fm>
Cc: a.hindborg@kernel.org, k.opasiak@samsung.com,
nab@linux-iscsi.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] configfs: handle unlinked target in configfs_depend_item_unlocked()
Date: Tue, 27 Oct 2026 05:50:49 -0700 [thread overview]
Message-ID: <auCeHAUGWXiSWMFW@gmail.com> (raw)
In-Reply-To: <20261022134443.1122318-1-sst@poczta.fm>
On Thu, Oct 22, 2026 at 03:44:42PM +0200, Slawomir Stepien wrote:
> configfs_depend_item_unlocked() starts by reading target->ci_group to
> find the target's subsystem and the configfs root, and dereferences it
> without checking for NULL. ci_group is only valid while the item is
> linked into the tree: it is set by link_group() during mkdir and
> cleared by unlink_group() during rmdir, both under the subsystem's
> su_mutex, which callers of the unlocked variant do not hold.
>
> A caller can therefore pass an item that is allocated but not linked.
> f_tcm does this from usbg_make_tpg(): a TCM function instance becomes
> visible to the target subsystem in tcm_alloc_inst()/tcm_set_name(),
> before configfs_mkdir() links it, and stays visible after
> configfs_rmdir() unlinks it until the final reference is dropped.
> Creating a TPG in either window makes configfs_is_root(&parent->cg_item)
> return false for a NULL parent, and the following parent->cg_subsys
> dereference crashes.
>
> An unlinked item is just a target that is not in the tree, which
> configfs_depend_prep() already reports as -ENOENT. It skips items
> marked CREATING or DROPPING, and rmdir marks an item DROPPING before
> unlinking it. Read ci_group once with READ_ONCE() and return -ENOENT
> if it is NULL.
>
> If the target is unlinked right after the read, the snapshot still
> points at the parent group: unlinking drops the child's reference on
> it but does not free it. The depend then fails in the tree scan, since
> the target is already marked DROPPING. The parent can only go away if
> it is itself removed in that window, which is the same theoretical
> race the root walk below already has for every caller of this
> function.
>
> Fixes: d79d75b5c518 ("fs: configfs: Add unlocked version of configfs_depend_item()")
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Slawomir Stepien <sst@poczta.fm>
Reviewed-by: Breno Leitao <leitao@debian.org>
next prev parent reply other threads:[~2026-10-27 12:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 13:44 Slawomir Stepien
2026-10-22 13:44 ` [PATCH 2/2] configfs: give the root inode its own lockdep class Slawomir Stepien
2026-10-27 12:51 ` Breno Leitao
2026-10-27 12:50 ` Breno Leitao [this message]
2026-10-27 13:27 ` [PATCH 1/2] configfs: handle unlinked target in configfs_depend_item_unlocked() Breno Leitao
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=auCeHAUGWXiSWMFW@gmail.com \
--to=leitao@debian.org \
--cc=a.hindborg@kernel.org \
--cc=k.opasiak@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nab@linux-iscsi.org \
--cc=sst@poczta.fm \
/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
all inboxes | Powered by JetHome®