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

[Breno Leitao <leitao@debian.org>]

On Wed, Aug 12, 2026 at 09:00:57AM +0200, Vasileios Almpanis wrote:
> 
> 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.

sorry for the delay, we were fixing a few things in configfs, and I've
tested and reviewed this patchset and it looks good. I will queue it.