Re: [PATCH] configfs: fix refcount warning in configfs_get_config_item()

[Joshua Crofts <joshua.crofts1@gmail.com>]

On Wed, 29 Jul 2026 15:21:25 +0530
Jeffin Philip <jeffinphilip14@gmail.com> wrote:

> On Wed, 29 Jul 2026 09:00 +0000
> Joshua Crofts <joshua.crofts1@gmail.com> wrote:
> 
> >On Wed, 29 Jul 2026 08:55:05 +0000
> >Joshua Crofts <joshua.crofts1@gmail.com> wrote:
> >  
> >> syzbot reported a "refcount_t: addition on 0; use-after-free" warning
> >> in configfs_get_config_item().
> >> 
> >> This occurs when configfs_get_config_item() races with a concurrent
> >> teardown (e.g. rmdir). When the target config_item's refcount drops to
> >> 0, configfs_get_config_item() calls config_item_get(), which
> >> unconditionally increments the refcount via kref_get(), triggering the
> >> refcount warning.
> >> 
> >> Fix this by using config_item_get_unless_zero(), which safely returns
> >> NULL if the refcount is already 0.
> >> Reported-by: syzbot+35790eb7861f8fc57382@syzkaller.appspotmail.com
> >> Closes: https://syzkaller.appspot.com/bug?extid=35790eb7861f8fc57382
> >> Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
> >> ---
> >>  fs/configfs/configfs_internal.h | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> diff --git a/fs/configfs/configfs_internal.h b/fs/configfs/configfs_internal.h
> >> index acdeea8e2..5448af3a8 100644
> >> --- a/fs/configfs/configfs_internal.h
> >> +++ b/fs/configfs/configfs_internal.h
> >> @@ -124,7 +124,7 @@ static inline struct config_item *configfs_get_config_item(struct dentry *dentry
> >>  	spin_lock(&dentry->d_lock);
> >>  	if (!d_unhashed(dentry)) {
> >>  		struct configfs_dirent * sd = dentry->d_fsdata;
> >> -		item = config_item_get(sd->s_element);
> >> +		item = config_item_get_unless_zero(sd->s_element);
> >>  	}
> >>  	spin_unlock(&dentry->d_lock);  
> 
> I tested this solution first on syzbot and well, it errored out. But on testing it on a local
> build, it seems to trigger a different warning in configfs_get() regarding atomic count. Could you please 
> look into it?

Yeah, I've no idea why syzbot keeps failing on "FATAL: Kernel too old",
especially when testing against upstream. As for the different warning,
that's odd, because when I booted the kernel with the patch in QEMU and
ran the reproducer nothing happened. Could you please send the warning
in it's entirety?

-- 
Kind regards,
Joshua Crofts