Bug 2541253 (CVE-2026-97950) - CVE-2026-97950 kernel: configfs: pin the symlink target's dirent instead of chasing ->ci_dentry
Summary: CVE-2026-97950 kernel: configfs: pin the symlink target's dirent instead of c...
Keywords:
Status: NEW
Alias: CVE-2026-97950
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-09-25 11:11 UTC by OSIDB Bzimport
Modified: 2026-09-29 22:39 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-09-25 11:11:11 UTC
In the Linux kernel, the following vulnerability has been resolved:

configfs: pin the symlink target's dirent instead of chasing ->ci_dentry

create_link() reads the target's configfs_dirent from
item->ci_dentry->d_fsdata, relying on the item reference taken by
get_target().  That reference pins the item, not its dentry: the dentry is
pinned by DCACHE_PERSISTENT, which configfs_remove_dir() releases via
simple_rmdir() while the item is still alive.  A symlink racing with rmdir
of its target can therefore find ->ci_dentry freed and its dirent
released, triggering WARN_ON(!atomic_read(&sd->s_count)) in configfs_get().

Take the dirent in get_target() as well, under ->d_lock and atomically
with the item reference, and pass it down to create_link().  A hashed
dentry has not been killed yet, so its ->d_fsdata reference keeps the
dirent alive there.


Note You need to log in before you can comment on or make changes to this bug.