Re: [PATCH 0/2] configfs: fix use-after-free of symlink target racing with rmdir

Vasileios Almpanis <[email protected]>
Newsgroups org.kernel.vger.stable,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 7/30/26 11:30 AM, Vasileios Almpanis wrote:
> syzkaller reported a slab-use-after-free in config_item_get() when
> symlink(2) races with rmdir(2) of the symlink target:
>
>    BUG: KASAN: slab-use-after-free in config_item_get+0x26/0x90
>     configfs_get_config_item fs/configfs/configfs_internal.h:127 [inline]
>     get_target fs/configfs/symlink.c:128 [inline]
>     configfs_symlink+0x4ab/0x1030 fs/configfs/symlink.c:185
>
> configfs_symlink() resolves the target with no locks, with the idea
> that a hashed dentry means a live config_item. configfs_rmdir() drops
> the last reference to the item before the dentry gets unhashed by
> d_delete() in vfs_rmdir(), so get_target() could take a reference on
> an already freed item.
>
> Patch 2 fixes this by unhashing the dentry in configfs_remove_dir(),
> before the item can be freed.  Patch 1 fixes a second lifetime bug in
> the same path that the earlier unhashing makes easy to hit: an item
> reference does not pin the item's dentry, so create_link() must not
> reach the target's configfs_dirent through ->ci_dentry.  The patches
> must be applied in this order.
>
> Tested with the syzkaller reproducer, which no longer triggers either
> the KASAN report or the s_count warning.
>
> Vasileios Almpanis (2):
>    configfs: pin the symlink target's dirent instead of chasing
>      ->ci_dentry
>    configfs: unhash the dentry before dropping the item in rmdir
>
>   fs/configfs/dir.c     |  9 +++++++++
>   fs/configfs/symlink.c | 24 ++++++++++++++++++++----
>   2 files changed, 29 insertions(+), 4 deletions(-)
>
>
Hi everyone,

Regarding this series, is there anything I could have done differently?
Any suggestions or advice would be greatly appreciated.

Thanks,
Vasileios
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.