CVE-2026-97950: configfs: pin the symlink target's dirent instead of chasing ->ci_dentry
In the Linux kernel, the following vulnerability has been resolved:
configfs: pin the symlink target's dirent instead of chasing ->cidentry
createlink() reads the target's configfsdirent from item->cidentry->dfsdata, relying on the item reference taken by gettarget(). That reference pins the item, not its dentry: the dentry is pinned by DCACHEPERSISTENT, which configfsremovedir() releases via simplermdir() while the item is still alive. A symlink racing with rmdir of its target can therefore find ->cidentry freed and its dirent released, triggering WARNON(!atomicread(&sd->scount)) in configfsget().
Take the dirent in gettarget() as well, under ->dlock and atomically with the item reference, and pass it down to createlink(). A hashed dentry has not been killed yet, so its ->dfsdata reference keeps the dirent alive there.
Affected Software
Event History
Frequently Asked Questions
What condition is required to trigger the issue?
A configfs symlink creation must race with removal of the symlink target directory. The target item can remain alive while its dentry and associated configfs dirent have been released by the directory removal path.
What symptom may indicate that a system encountered this bug?
The described failure triggers WARN_ON(!atomic_read(&sd->s_count)) in configfs_get(). This warning can occur when symlink creation dereferences the target item's ci_dentry after a concurrent rmdir has freed that dentry and released its dirent.
What does the fix change?
The fix takes and retains a reference to the target configfs dirent in get_target(), while holding d_lock and atomically with the item reference. It then passes that dirent to create_link(), rather than retrieving it later through ci_dentry.