CVE-2026-89768: fs: fix user path of nested backing files

In the Linux kernel, the following vulnerability has been resolved:

fs: fix user path of nested backing files

backingfileopen() derives the path to be stored in the new backing file from userfile->fpath. This is incorrect when userfile 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 fpath") the fpath 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 fileuserpath() from ovlopenrealfile(). However, commit 6af36aeb147a ("lsm: add backingfile LSM hooks") changed the first argument of backingfileopen() from the user path back to the user file and derived the path from userfile->fpath 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 fpath of the intermediate backing file, whose mount is a private clone that dpath() cannot resolve.

Fix this by using fileuserpath(), which returns the outermost user-visible path for backing files and falls back to &userfile->fpath 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 backingfileopen() callers, fuse passthrough and erofs ishare, when their user file is itself a backing file.

backingtmpfileopen() has the same pattern but is not affected: it is only called by ovlcreatetmpfile() for the upper layer, and another overlayfs is rejected as upperdir by the DCACHEOPREAL check in ovlmountdircheck(), so its userfile can never be a backing file.