CVE-2026-89768fs: fix user path of nested backing files
- —Not scoredno CVSS score yet
- 0.19%Exploitation in 30 daysEPSS · top 91% of all CVEs
- NoKnown exploitednot in CISA's KEV catalog
- NonePublic exploitsnone known yet
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.
Timeline
ID reserved
By Linux
Published
- 38 days later
· 38 days later
Record updated
Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.
Scores
No CVSS score yet: neither the CNA, CISA nor NVD has scored this CVE. NVD status: Received.
- EPSS (exploitation in 30 days)
- 0.19% · top 91% of all CVEs (14 Nov 2026)
The list uses the assigner's score when there is one, then CISA's, then NVD's: Not scored.
Affected products
- affected 5b6aa9a843205da92d860e5011a7b29062a76b8f – < 88c927a63dc717b6d46b20fe13ea713916e49089
- affected 5dfcb15974e7d0f96aca278dd9f1b85df91523ef – < c03114634d342648bd34910aa8fb88007e92cc3c
- affected 6af36aeb147a06dea47c49859cd6ca5659aeb987 – < a35cc21355734e1acb89973d9be90ca8e4c3ed2f
- affected 6af36aeb147a06dea47c49859cd6ca5659aeb987 – < f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d
- affected 41c5b269af8b1f0bffcab7766a793f294ae6764e
- affected 27e795afba0018b0ea9460dbad4bd706d1ba5ee0
- affected 6.12.95 – < 6.12.109
- affected 6.18.38 – < 6.18.50
- affected 6.6.144 – < 6.7
- affected 7.0.4 – < 7.1
- affected 7.1
- unaffected < 7.1
- unaffected 6.12.109 – ≤ 6.12.*
- unaffected 6.18.50 – ≤ 6.18.*
- unaffected 7.2.4 – ≤ 7.2.*
- unaffected 7.3 – ≤ *
References
References4
- https://git.kernel.org/stable/c/88c927a63dc717b6d46b20fe13ea713916e49089 (opens in a new tab)
- https://git.kernel.org/stable/c/c03114634d342648bd34910aa8fb88007e92cc3c (opens in a new tab)
- https://git.kernel.org/stable/c/a35cc21355734e1acb89973d9be90ca8e4c3ed2f (opens in a new tab)
- https://git.kernel.org/stable/c/f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d (opens in a new tab)
Sources
The same CVE in the primary databases and aggregators, to check against.
- CVE.org record (opens in a new tab)
- CVE List JSON (GitHub) (opens in a new tab)
- NVD (opens in a new tab)
- FIRST EPSS (opens in a new tab)
- EUVD EUVD-2026-76680 (opens in a new tab)
- OSV.dev (opens in a new tab)
- GitHub Advisories (opens in a new tab)
- CIRCL Vulnerability-Lookup (opens in a new tab)
Badge for a README or a ticket
[](https://cveledger.app/cve/CVE-2026-89768)Record last updated .