CVE-2026-89768

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.