From: Breno Leitao <leitao@debian.org>
To: Drif Abdelmalek Mohamed Said <drifabdelmalekmohamedsaid@gmail.com>
Cc: Andreas Hindborg <a.hindborg@kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
syzkaller-bugs@googlegroups.com,
syzbot+63336d70e1af377d7388@syzkaller.appspotmail.com,
Ran Hongyun <ranhongyun1@huawei.com>
Subject: Re: [PATCH v2] configfs: fix slab-UAF Write in config_item_put
Date: Thu, 5 Nov 2026 03:29:36 -0800 [thread overview]
Message-ID: <auxn5snXPQJLR2z1@gmail.com> (raw)
In-Reply-To: <20261023162906.2938-1-drifabdelmalekmohamedsaid@gmail.com>
On Fri, Oct 23, 2026 at 05:29:06PM +0100, Drif Abdelmalek Mohamed Said wrote:
> syzbot reported:
Please drop this full log, given we have a link to the syzbot report.
> This is a race between a thread creating a symlink and another one
> doing rmdir on a parent (or ancestor) directory of symlink creation dir.
>
> configfs_symlink() takes a reference on parent_item, the directory the
> link is created in, and then drops the directory inode lock around
> get_target(). While the lock is dropped, a concurrent rmdir can remove
> the group that parent_item belongs to.
>
> If parent_item is a default group embedded in a larger object, such as
> nvmet_port.subsys_group, the reference on the embedded item does not
> keep the containing object alive. rmdir frees the object, and the final
> config_item_put(parent_item) in configfs_symlink() then decrements a
> kref inside freed memory.
>
> Fix this by not holding parent_item across the unlocked window. Drop
> the reference before inode_unlock() and look it up again from
> dentry->d_parent after inode_lock(). configfs_get_config_item() returns
> NULL if the parent dentry was unhashed in the meantime, in which case
> release the target references and return -ENOENT.
>
> Re-looking up parent_item is not sufficient on its own.
> configfs_get_config_item() only fails if the parent dentry has been
> unhashed, and the rmdir path in another thread may skip that: if
> simple_rmdir() failed, the earlier d_drop() was skipped, so the dentry
> can stay hashed even though the directory has already been detached.
>
> Such a directory was created as a default group (CONFIGFS_USET_DIR), so
> configfs_rmdir() takes the CONFIGFS_USET_DIR branch and calls
> configfs_detach_group(). detach_groups() then marks each child inode
> S_DEAD (d_inode(child)->i_flags |= S_DEAD). Check IS_DEADDIR(dir)
> after retaking the inode lock and before taking a reference on the
> parent, and return -ENOENT. This also rejects a detached directory
> whose dentry is still hashed.
This is LLM-heavy and hard to follow, would you be able to make it a bit
more human?
> ---
> v2: Added check for dead dir, this would be helpful when configfs_remove_dir skips
> unhashing the dentry.
> v1: https://lore.kernel.org/all/20261017123748.4430-1-drifabdelmalekmohamedsaid@gmail.com/T/
> fs/configfs/symlink.c | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/fs/configfs/symlink.c b/fs/configfs/symlink.c
> index 89178f5d371a..7d746a10c369 100644
> --- a/fs/configfs/symlink.c
> +++ b/fs/configfs/symlink.c
> @@ -196,11 +196,26 @@ int configfs_symlink(const struct mnt_idmap *idmap, struct inode *dir,
> *
> * AV, a thoroughly annoyed bastard.
> */
> +
> + /* Put the reference back, retake and check after relocking*/
Nit space before */
> + config_item_put(parent_item);
> + parent_item = NULL;
Why do you need to set it to NULL here?
> inode_unlock(dir);
> ret = get_target(symname, &target_item, &target_sd, dentry->d_sb);
> inode_lock(dir);
> if (ret)
> - goto out_put;
> + goto out_put; /* config_item_put on NULL, no problem */
This comment is not necessary.
Thanks for the patch,
--breno
next prev parent reply other threads:[~2026-11-05 11:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 16:29 [PATCH v2] configfs: fix slab-UAF Write in config_item_put Drif Abdelmalek Mohamed Said
2026-10-26 2:33 ` Ran Hongyun
2026-11-04 11:29 ` DRIF ABDELMALEK MOHAMED SAID
2026-11-05 11:29 ` Breno Leitao [this message]
2026-11-05 16:53 ` DRIF ABDELMALEK MOHAMED SAID
[not found] <20261023174739.5884-1-drifabdelmalekmohamedsaid@gmail.com>
2026-10-23 17:47 ` syzbot
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=auxn5snXPQJLR2z1@gmail.com \
--to=leitao@debian.org \
--cc=a.hindborg@kernel.org \
--cc=brauner@kernel.org \
--cc=drifabdelmalekmohamedsaid@gmail.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ranhongyun1@huawei.com \
--cc=syzbot+63336d70e1af377d7388@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
/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.