Re: [PATCH 1/2] configfs: handle unlinked target in configfs_depend_item_unlocked()

From: Breno Leitao

Date: Tue Oct 27 2026 - 08:57:07 EST


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@xxxxxxxxx>

Reviewed-by: Breno Leitao <leitao@xxxxxxxxxx>