---
id: CVE-2026-97950
title: |-
  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 th…
summary: |-
  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 th…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 7063fbf2261194f72ee75afca67b3b38b554b5fa <
    4f54beb2e7f6d399396466682fba3539bcdcb414
  - >-
    Linux >= 7063fbf2261194f72ee75afca67b3b38b554b5fa <
    d47c5de1cd6bfbe1067fc310bf90e4e00205e839
  - >-
    Linux >= 7063fbf2261194f72ee75afca67b3b38b554b5fa <
    a7c1290eef60711c10289c056ad32ed1f2b47b12
  - Linux 2.6.16
published: '2026-09-25'
updated: '2026-09-25'
sourceUpdated: '2026-09-25T11:17:22.567'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-97950'
references:
  - url: 'https://git.kernel.org/stable/c/4f54beb2e7f6d399396466682fba3539bcdcb414'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/a7c1290eef60711c10289c056ad32ed1f2b47b12'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/d47c5de1cd6bfbe1067fc310bf90e4e00205e839'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
  - cve.org
ingestedAt: '2026-09-25T11:06:38.880Z'
---

## Overview

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.

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.