{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  fs: fix user path of nested backing files  backing_file_open() derives the path to be stored in the new backing file from user_file-\u003ef_path.  This is incorrect when user_file itself is a backing file, which is the case for nested stacking filesystems, e.g. overlayfs mounts where the lowerdir of one overlayfs is the merged directory of another.  Since commit def3ae83da02 (\"fs: store real path instead of fake path in backing file f_path\") the f_path of a backing file holds the real path of the intermediate layer, not the path that the user opened.  Commit 924577e4f6ca (\"ovl: Fix nested backing file paths\") fixed this for such configurations by passing file_user_path() from ovl_open_realfile().  However, commit 6af36aeb147a (\"lsm: add backing_file LSM hooks\") changed the first argument of backing_file_open() from the user path back to the user file and derived the path from user_file-\u003ef_path again, silently re-introducing the problem.  As a result, files mapped through a nested overlayfs show the wrong path in /proc/\u003cpid\u003e/maps and in perf/ftrace mmap records.  For example, with two nested overlayfs mounts:    mkdir -p /ovl/{lower,upper,work,merged} /ovl/nested   echo hello \u003e /ovl/lower/foo   mount -t overlay overlay \\ \t-o lowerdir=/ovl/lower,upperdir=/ovl/upper,workdir=/ovl/work \\ \t/ovl/merged   # at least two lowerdirs are needed when upperdir is nonexistent   mount -t overlay overlay \\ \t-o lowerdir=/ovl/merged:/ovl/lower /ovl/nested  mapping /ovl/nested/foo shows a disconnected path instead of the user path:    # readlink /proc/self/fd/3   /ovl/nested/foo   # grep foo /proc/self/maps   7f6e2c100000-7f6e2c101000 r--s 00000000 00:24 15813027 /foo  The bogus path is derived from the f_path of the intermediate backing file, whose mount is a private clone that d_path() cannot resolve.  Fix this by using file_user_path(), which returns the outermost user-visible path for backing files and falls back to \u0026user_file-\u003ef_path for regular files.  This restores the behavior of commit 924577e4f6ca (\"ovl: Fix nested backing file paths\") for overlayfs and also fixes the same problem for the other backing_file_open() callers, fuse passthrough and erofs ishare, when their user file is itself a backing file.  backing_tmpfile_open() has the same pattern but is not affected: it is only called by ovl_create_tmpfile() for the upper layer, and another overlayfs is rejected as upperdir by the DCACHE_OP_REAL check in ovl_mount_dir_check(), so its user_file can never be a backing file.",
  "id": "DEBIAN-CVE-2026-89768",
  "modified": "2026-09-12T08:47:22.581500659Z",
  "published": "2026-09-11T20:20:08.090Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-89768"
    }
  ],
  "upstream": [
    "CVE-2026-89768"
  ]
}