CVE-2026-97949: configfs: unhash the dentry before dropping the item in rmdir
In the Linux kernel, the following vulnerability has been resolved:
configfs: unhash the dentry before dropping the item in rmdir
configfsgetconfigitem() treats a hashed dentry as proof that sd->selement is a live configitem. configfsrmdir() breaks that: simplermdir() leaves the dentry hashed, the last reference to the item is dropped right after, and the dentry is only unhashed by ddelete() once ->rmdir() has returned. configfssymlink() resolves its target holding no lock on it, so gettarget() can land in that window:
BUG: KASAN: slab-use-after-free in configitemget+0x26/0x90 gettarget fs/configfs/symlink.c:128 [inline] configfssymlink+0x4ab/0x1030 fs/configfs/symlink.c:185
Unhash in configfsremovedir(), while the item is still guaranteed to be there. A reference obtained just before that stays harmless, as createlink() rechecks CONFIGFSUSETDROPPING, already set by configfsdetachprep(). Both configfsunregistersubsystem() paths ddrop() after detaching, so this only makes rmdir match them.
Affected Software
Event History
Frequently Asked Questions
What conditions are needed to trigger the use-after-free?
The race requires a configfs directory removal and configfs symlink target resolution to overlap. During the window after simple_rmdir() drops the item's last reference but before d_delete() unhashes the dentry, get_target() can treat the still-hashed dentry as referring to a live config_item.
Which systems are realistically exposed?
Systems using configfs are exposed when configfs rmdir activity can occur concurrently with configfs symlink creation or target lookup. The provided data does not state whether configfs is enabled or used by default on any particular system.
How might this appear during testing or investigation?
The reported manifestation is a KASAN slab-use-after-free in config_item_get(), reached through get_target() during configfs_symlink(). The trace identifies fs/configfs/symlink.c as the target-resolution path involved.
What does the fix change?
The fix unhashed the dentry in configfs_remove_dir() while the config_item is still guaranteed to exist, rather than waiting for d_delete() after rmdir returns. A reference acquired immediately before removal remains harmless because create_link() rechecks CONFIGFS_USET_DROPPING.