mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

      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®