fs: fix user path of nested backing files
Summary
| CVE | CVE-2026-89768 |
| State | PUBLISHED |
| Assigner | Linux |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-09-11 20:20:08 UTC |
| Updated | 2026-09-11 20:20:08 UTC |
| Description | 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. |
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|
| CNA |
Linux |
Linux |
affected 5b6aa9a843205da92d860e5011a7b29062a76b8f 88c927a63dc717b6d46b20fe13ea713916e49089 git |
Not specified |
| CNA |
Linux |
Linux |
affected 5dfcb15974e7d0f96aca278dd9f1b85df91523ef c03114634d342648bd34910aa8fb88007e92cc3c git |
Not specified |
| CNA |
Linux |
Linux |
affected 6af36aeb147a06dea47c49859cd6ca5659aeb987 a35cc21355734e1acb89973d9be90ca8e4c3ed2f git |
Not specified |
| CNA |
Linux |
Linux |
affected 6af36aeb147a06dea47c49859cd6ca5659aeb987 f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d git |
Not specified |
| CNA |
Linux |
Linux |
affected 41c5b269af8b1f0bffcab7766a793f294ae6764e git |
Not specified |
| CNA |
Linux |
Linux |
affected 27e795afba0018b0ea9460dbad4bd706d1ba5ee0 git |
Not specified |
| CNA |
Linux |
Linux |
affected 6.12.95 6.12.109 semver |
Not specified |
| CNA |
Linux |
Linux |
affected 6.18.38 6.18.50 semver |
Not specified |
| CNA |
Linux |
Linux |
affected 6.6.144 6.7 semver |
Not specified |
| CNA |
Linux |
Linux |
affected 7.0.4 7.1 semver |
Not specified |
| CNA |
Linux |
Linux |
affected 7.1 |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.1 semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.12.109 6.12.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.18.50 6.18.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.2.4 7.2.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.3-rc1 * original_commit_for_fix |
Not specified |
References
| Reference | Source | Link | Tags |
|---|
| git.kernel.org/stable/c/f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/88c927a63dc717b6d46b20fe13ea713916e49089 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/a35cc21355734e1acb89973d9be90ca8e4c3ed2f |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/c03114634d342648bd34910aa8fb88007e92cc3c |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| CVE Program record |
CVE.ORG |
www.cve.org |
canonical |
| NVD vulnerability detail |
NVD |
nvd.nist.gov |
canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.