From: Breno Leitao <leitao@debian.org>
To: Yingjie Wang <x-professor@outlook.com>
Cc: "a.hindborg@kernel.org" <a.hindborg@kernel.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
Yingjie Wang <1075151112@qq.com>
Subject: Re: [PATCH] configfs: protect symlink source callbacks from removal
Date: Fri, 6 Nov 2026 08:16:06 -0800 [thread overview]
Message-ID: <au39EinX6Xhj4yoj@gmail.com> (raw)
In-Reply-To: <20261105134514.2890692-1-x-professor@outlook.com>
On Thu, Nov 05, 2026 at 01:45:17PM +0000, Yingjie Wang wrote:
> From: Yingjie Wang <1075151112@qq.com>
>
> configfs_symlink() drops the source directory inode lock while resolving
> its target. A concurrent rmdir() of the source item can take that lock,
> detach the item and clear its ci_group in unlink_obj(). configfs_symlink()
> then reacquires the lock and calls the source ->allow_link() callback on
> the detached item. Its config_item reference keeps the object allocated,
> but not attached to the hierarchy.
>
> The UVC gadget format callback reads src->ci_group->cg_subsys to take the
> subsystem mutex and faults on the cleared pointer. Racing symlink() into
> a UVC format directory with rmdir() of that directory produces:
>
> BUG: KASAN: null-ptr-deref in uvcg_format_allow_link+0x2a/0x140
> Read of size 8 at addr 0000000000000060 by task configfs_race/291
> Call Trace:
> uvcg_format_allow_link+0x2a/0x140
> configfs_symlink+0x3f2/0x870
> vfs_symlink+0xc0/0x2a0
> filename_symlinkat+0x118/0x2b0
> __x64_sys_symlink+0x50/0x70
>
> Creating the items needs the privileges required to manage configfs.
>
> Rechecking ci_group after relocking would cover rmdir(), which holds the
> source inode lock until unlink_obj() returns. It would not cover
> configfs_unregister_group() and configfs_unregister_subsystem(): both
> clear ci_group in unlink_group() while the source inode lock is not held,
> so the check could become stale before the callback runs.
>
> Take the source fragment read lock after reacquiring the inode lock and
> hold it through allow_link(), create_link() and drop_link(). rmdir() and
> both unregister paths mark the fragment dead under the write lock before
> they unlink the item, so a concurrent removal either waits for the
> callback to finish or makes the symlink fail with -ENOENT.
>
> Built from the same configuration, the kernel without this change faulted
> within 1,000 iterations, while the kernel with it completed 10,000
> iterations with no report. The reproducer covers the rmdir() path; the
> unregister paths were checked by code inspection.
>
> Fixes: 351e5d869e5a ("configfs: fix a deadlock in configfs_symlink()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Yingjie Wang <1075151112@qq.com>
How this patch was tested?
I applied this patch to next-20261104 and raced symlink() inside
ports/1/subsystems against a mkdir/rmdir loop on ports/1. KASAN fired
within a second:
BUG: KASAN: slab-use-after-free in config_item_put+0x48/0x180
Write of size 4 at addr ff110001068d64b4 by task brute/170
Call Trace:
config_item_put+0x48/0x180
configfs_symlink+0x4eb/0x770
vfs_symlink+0x25b/0x4b0
filename_symlinkat+0x10d/0x2f0
...
Allocated by task 168:
__kmalloc_cache_noprof+0x26c/0x4c0
nvmet_ports_make+0xcc/0xd10
configfs_mkdir+0x44d/0x810
...
Freed by task 168:
kfree+0x150/0x4f0
config_item_put+0x139/0x180
next prev parent reply other threads:[~2026-11-06 16:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 13:45 [PATCH] configfs: protect symlink source callbacks from removal Yingjie Wang
2026-11-06 16:16 ` Breno Leitao [this message]
2026-11-07 9:42 ` Yingjie Wang
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=au39EinX6Xhj4yoj@gmail.com \
--to=leitao@debian.org \
--cc=1075151112@qq.com \
--cc=a.hindborg@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=x-professor@outlook.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.