CVE-2026-89768 in Linux
Summary
by MITRE • 09/11/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/12/2026
The Linux kernel contains a vulnerability within the filesystem subsystem related to how paths are resolved for nested backing files, specifically affecting stacked filesystems like overlayfs. The core issue lies in the implementation of the backing_file_open function, which is responsible for deriving the path stored in new backing file structures from the f_path member of the user-provided file object. This approach fails when the user_file itself is already a backing file, a scenario that occurs during nested stacking configurations such as overlayfs mounts where one layer's lower directory points to another overlayfs merged directory. Historically, commit def3ae83da02 established that backing files should store real paths rather than fake ones, but subsequent changes inadvertently reintroduced the flaw by reverting the argument passed to backing_file_open back to the user file and deriving its path directly from f_path. This regression was partially addressed in a prior fix for overlayfs via commit 924577e4f6ca, which utilized file_user_path to correctly resolve paths, but this correction was lost when LSM hooks were added in commit 6af36aeb147a, causing the system to silently revert to using the incorrect intermediate backing file path.
The operational impact of this vulnerability manifests primarily through the display of incorrect or disconnected paths in diagnostic and monitoring interfaces that rely on accurate file mapping information. Specifically, files mapped through nested overlayfs mounts appear with bogus paths in /proc/<pid>/maps and perf/ftrace mmap records rather than the expected user-visible paths. For instance, when a file is accessed via a deeply nested overlay structure, tools reading process memory maps may report a path that cannot be resolved by standard kernel functions like d_path because it references an intermediate layer with a private mount clone. This discrepancy hinders system administrators and security analysts from accurately identifying the source of mapped files, complicating forensic analysis, debugging efforts, and compliance auditing processes where precise file lineage is critical for understanding data flow and access patterns within complex containerized or layered storage environments.
From a technical perspective, this flaw aligns with CWE-20 Improper Input Validation as it involves mishandling the context of file paths during internal kernel operations, leading to incorrect state representation. It also relates to CWE-754: Improper Check for Unusual or Exceptional Conditions because the code fails to account for the recursive nature of backing files in nested filesystem hierarchies. In terms of MITRE ATT&CK mapping, while not a direct exploitation vector for privilege escalation, this issue impacts observability and detection capabilities, potentially falling under T1078: Valid Accounts if an attacker relies on obscured file paths to evade monitoring tools that parse /proc/<pid>/maps or similar interfaces. The vulnerability essentially creates a blind spot in the kernel's ability to correctly trace user-visible file locations through multiple layers of abstraction, undermining the integrity of system telemetry data used for security posture assessment and incident response.
The resolution involves modifying backing_file_open to utilize file_user_path instead of directly accessing f_path from the user file object. This function is designed to return the outermost user-visible path for backing files while gracefully falling back to standard behavior for regular files, thereby restoring the correct path resolution logic originally implemented in earlier fixes. This change ensures that overlayfs, fuse passthrough, and erofs ishare all correctly resolve paths even when their underlying user file is itself a backing file. Additionally, it was determined that backing_tmpfile_open follows a similar pattern but remains unaffected because its usage context restricts the input to upper layer files only, which are explicitly rejected if they represent another overlayfs mount due to DCACHE_OP_REAL checks in ovl_mount_dir_check.
To mitigate this vulnerability and prevent recurrence, system administrators should ensure their Linux kernels are updated with patches that include these filesystem path resolution corrections. For environments running older kernel versions where immediate patching is not feasible, limiting the use of deeply nested overlayfs configurations can reduce exposure to incorrect path reporting in monitoring tools. Furthermore, security teams relying on /proc/<pid>/maps for threat hunting should be aware that paths derived from such maps may require additional validation or cross-referencing with other system logs if they appear disconnected or unresolvable. Regular auditing of kernel updates and prioritizing patches related to filesystem integrity are essential steps in maintaining accurate observability across complex storage architectures.