---
id: CVE-2026-89768
title: 'fs: fix user path of nested backing files'
summary: |-
  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->f_path.  This is incorrect when use…
severity: medium
cvss: 5.5
cvssVector: 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'
cvssSource: vendor
cwe:
  - CWE-41
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 5b6aa9a843205da92d860e5011a7b29062a76b8f <
    88c927a63dc717b6d46b20fe13ea713916e49089
  - >-
    Linux >= 5dfcb15974e7d0f96aca278dd9f1b85df91523ef <
    c03114634d342648bd34910aa8fb88007e92cc3c
  - >-
    Linux >= 6af36aeb147a06dea47c49859cd6ca5659aeb987 <
    a35cc21355734e1acb89973d9be90ca8e4c3ed2f
  - >-
    Linux >= 6af36aeb147a06dea47c49859cd6ca5659aeb987 <
    f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d
  - Linux 41c5b269af8b1f0bffcab7766a793f294ae6764e
  - Linux 27e795afba0018b0ea9460dbad4bd706d1ba5ee0
  - Linux >= 6.12.95 < 6.12.109
  - Linux >= 6.18.38 < 6.18.50
  - Linux >= 6.6.144 < 6.7
  - Linux >= 7.0.4 < 7.1
  - Linux 7.1
published: '2026-09-11'
updated: '2026-10-19'
sourceUpdated: '2026-10-19T08:52:21.786Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-89768'
references:
  - url: 'https://git.kernel.org/stable/c/88c927a63dc717b6d46b20fe13ea713916e49089'
  - url: 'https://git.kernel.org/stable/c/c03114634d342648bd34910aa8fb88007e92cc3c'
  - url: 'https://git.kernel.org/stable/c/a35cc21355734e1acb89973d9be90ca8e4c3ed2f'
  - url: 'https://git.kernel.org/stable/c/f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d'
  - url: >-
      https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-89768.json
  - url: 'https://access.redhat.com/security/cve/CVE-2026-89768'
  - url: 'https://bugzilla.redhat.com/show_bug.cgi?id=2532171'
  - url: 'https://www.cve.org/CVERecord?id=CVE-2026-89768'
  - url: 'https://nvd.nist.gov/vuln/detail/CVE-2026-89768'
  - url: >-
      https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-89768.mbox
tags:
  - cve.org
  - csaf
  - vex
  - red-hat
epss: 0.00191
epssPercentile: 0.0873
ingestedAt: '2026-09-14T11:11:19.884Z'
---

## Overview

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->f_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->f_path again, silently re-introducing
the problem.

As a result, files mapped through a nested overlayfs show the wrong
path in /proc/<pid>/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 > /ovl/lower/foo
  mount -t overlay overlay \
	-o lowerdir=/ovl/lower,upperdir=/ovl/upper,workdir=/ovl/work \
	/ovl/merged
  # at least two lowerdirs are needed when upperdir is nonexistent
  mount -t overlay overlay \
	-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
&user_file->f_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.

## Affected

- `Linux >= 5b6aa9a843205da92d860e5011a7b29062a76b8f < 88c927a63dc717b6d46b20fe13ea713916e49089`
- `Linux >= 5dfcb15974e7d0f96aca278dd9f1b85df91523ef < c03114634d342648bd34910aa8fb88007e92cc3c`
- `Linux >= 6af36aeb147a06dea47c49859cd6ca5659aeb987 < a35cc21355734e1acb89973d9be90ca8e4c3ed2f`
- `Linux >= 6af36aeb147a06dea47c49859cd6ca5659aeb987 < f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d`
- `Linux 41c5b269af8b1f0bffcab7766a793f294ae6764e`
- `Linux 27e795afba0018b0ea9460dbad4bd706d1ba5ee0`
- `Linux >= 6.12.95 < 6.12.109`
- `Linux >= 6.18.38 < 6.18.50`
- `Linux >= 6.6.144 < 6.7`
- `Linux >= 7.0.4 < 7.1`
- `Linux 7.1`

## Remediation

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

## Vendor advisories

- **Red Hat VEX** · Moderate · affected: Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 9, Red Hat OpenShift Container Platform 4 · no fix planned: Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 9, Red Hat OpenShift Container Platform 4 · updated 2026-09-21 · [vex](https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-89768.json)