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
prev parent reply other threads:[~2026-11-06 16:16 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 13:45 Yingjie Wang
2026-11-06 16:16 ` Breno Leitao [this message]
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 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®