CVE-2026-89768
NoneCVSS
—
EPSS
0.2%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
On Linux systems using layered file setups, certain file locations may appear incorrectly in monitoring and diagnostic tools, making it harder to understand exactly which files are being accessed.
- Exploitation
- Other
- Attacker needs
- None
- Complexity
- Theoretical
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Information Disclosure
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Incorrect derivation of user-visible paths for nested backing files causes backing_file_open callers to store and expose intermediate private mount paths instead of the outermost user path, resulting in disconnected or bogus entries appearing in /proc/<pid>/maps and perf/ftrace mmap records.
Why it matters to the business
Monitoring, forensics, and performance tools may display misleading file locations on systems using stacked overlay filesystems, complicating incident response and compliance auditing without altering actual file contents or access controls.
How an attack unfolds
An attacker with local access maps a file through nested overlay mounts; the kernel returns the private intermediate path from the backing file's f_path rather than the user-visible path via file_user_path, causing path disclosure in process memory maps and trace records.
How to fix it
Update the Linux kernel to a version containing the fix that restores use of file_user_path inside backing_file_open for all callers including overlayfs, fuse passthrough, and erofs ishare.
How to confirm the fix worked
After patching, recreate the nested overlay scenario and confirm that readlink on the mapped file descriptor and entries in /proc/<pid>/maps both report the original user path rather than a disconnected intermediate path.
Typical attack path
- Set up two nested overlayfs mounts where the lowerdir of the outer mount is the merged dir of the inner mount
- Open and map a file from the outermost merged directory
- Inspect /proc/self/maps or capture perf/ftrace mmap events to observe the incorrect intermediate path
How to detect it
Search process memory maps, perf mmap records, and ftrace output for paths that resolve to private overlay mount clones instead of expected user-visible locations; correlate with processes that open files under nested overlay directories.
What your security team should do
- Prioritize kernel updates on systems using overlayfs or other stacked filesystems for production workloads
- Review any custom monitoring or forensic scripts that parse /proc maps or perf data for reliance on accurate user paths
- Add kernel version checks to vulnerability scanning pipelines for this class of backing-file path handling issues
The record
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 packages
| Ecosystem | Package | Introduced | Fixed |
|---|