{"id":"CVE-2026-89768","title":"fs: fix user path of nested backing files","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nfs: fix user path of nested backing files\n\nbacking_file_open() derives the path to be stored in the new backing\nfile from user_file->f_path.  This is incorrect when use…","severity":"medium","cvss":5.5,"cvssVector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","cvssSource":"vendor","cwe":["CWE-41"],"vendor":"Linux","product":"Linux","affected":["Linux >= 5b6aa9a843205da92d860e5011a7b29062a76b8f < 88c927a63dc717b6d46b20fe13ea713916e49089","Linux >= 5dfcb15974e7d0f96aca278dd9f1b85df91523ef < c03114634d342648bd34910aa8fb88007e92cc3c","Linux >= 6af36aeb147a06dea47c49859cd6ca5659aeb987 < a35cc21355734e1acb89973d9be90ca8e4c3ed2f","Linux >= 6af36aeb147a06dea47c49859cd6ca5659aeb987 < f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d","Linux 41c5b269af8b1f0bffcab7766a793f294ae6764e","Linux 27e795afba0018b0ea9460dbad4bd706d1ba5ee0","Linux >= 6.12.95 < 6.12.109","Linux >= 6.18.38 < 6.18.50","Linux >= 6.6.144 < 6.7","Linux >= 7.0.4 < 7.1","Linux 7.1"],"published":"2026-09-11","updated":"2026-10-19","sourceUpdated":"2026-10-19T08:52:21.786Z","source":"CVEORG","sourceUrl":"https://www.cve.org/CVERecord?id=CVE-2026-89768","references":[{"url":"https://git.kernel.org/stable/c/88c927a63dc717b6d46b20fe13ea713916e49089"},{"url":"https://git.kernel.org/stable/c/c03114634d342648bd34910aa8fb88007e92cc3c"},{"url":"https://git.kernel.org/stable/c/a35cc21355734e1acb89973d9be90ca8e4c3ed2f"},{"url":"https://git.kernel.org/stable/c/f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d"},{"url":"https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-89768.json"},{"url":"https://access.redhat.com/security/cve/CVE-2026-89768"},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2532171"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-89768"},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89768"},{"url":"https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-89768.mbox"}],"tags":["cve.org","csaf","vex","red-hat"],"epss":0.00191,"epssPercentile":0.0873,"ingestedAt":"2026-09-14T11:11:19.884Z","slug":"CVE-2026-89768","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: fix user path of nested backing files\n\nbacking_file_open() derives the path to be stored in the new backing\nfile from user_file->f_path.  This is incorrect when user_file itself\nis a backing file, which is the case for nested stacking filesystems,\ne.g. overlayfs mounts where the lowerdir of one overlayfs is the merged\ndirectory of another.  Since commit def3ae83da02 (\"fs: store real path\ninstead of fake path in backing file f_path\") the f_path of a backing\nfile holds the real path of the intermediate layer, not the path that\nthe user opened.\n\nCommit 924577e4f6ca (\"ovl: Fix nested backing file paths\") fixed this\nfor such configurations by passing file_user_path() from\novl_open_realfile().  However, commit 6af36aeb147a (\"lsm: add\nbacking_file LSM hooks\") changed the first argument of\nbacking_file_open() from the user path back to the user file and\nderived the path from user_file->f_path again, silently re-introducing\nthe problem.\n\nAs a result, files mapped through a nested overlayfs show the wrong\npath in /proc/<pid>/maps and in perf/ftrace mmap records.  For example,\nwith two nested overlayfs mounts:\n\n  mkdir -p /ovl/{lower,upper,work,merged} /ovl/nested\n  echo hello > /ovl/lower/foo\n  mount -t overlay overlay \\\n\t-o lowerdir=/ovl/lower,upperdir=/ovl/upper,workdir=/ovl/work \\\n\t/ovl/merged\n  # at least two lowerdirs are needed when upperdir is nonexistent\n  mount -t overlay overlay \\\n\t-o lowerdir=/ovl/merged:/ovl/lower /ovl/nested\n\nmapping /ovl/nested/foo shows a disconnected path instead of the user\npath:\n\n  # readlink /proc/self/fd/3\n  /ovl/nested/foo\n  # grep foo /proc/self/maps\n  7f6e2c100000-7f6e2c101000 r--s 00000000 00:24 15813027 /foo\n\nThe bogus path is derived from the f_path of the intermediate backing\nfile, whose mount is a private clone that d_path() cannot resolve.\n\nFix this by using file_user_path(), which returns the outermost\nuser-visible path for backing files and falls back to\n&user_file->f_path for regular files.  This restores the behavior of\ncommit 924577e4f6ca (\"ovl: Fix nested backing file paths\") for\noverlayfs and also fixes the same problem for the other\nbacking_file_open() callers, fuse passthrough and erofs ishare, when\ntheir user file is itself a backing file.\n\nbacking_tmpfile_open() has the same pattern but is not affected: it is\nonly called by ovl_create_tmpfile() for the upper layer, and another\noverlayfs is rejected as upperdir by the DCACHE_OP_REAL check in\novl_mount_dir_check(), so its user_file can never be a backing file.\n\n## Affected\n\n- `Linux >= 5b6aa9a843205da92d860e5011a7b29062a76b8f < 88c927a63dc717b6d46b20fe13ea713916e49089`\n- `Linux >= 5dfcb15974e7d0f96aca278dd9f1b85df91523ef < c03114634d342648bd34910aa8fb88007e92cc3c`\n- `Linux >= 6af36aeb147a06dea47c49859cd6ca5659aeb987 < a35cc21355734e1acb89973d9be90ca8e4c3ed2f`\n- `Linux >= 6af36aeb147a06dea47c49859cd6ca5659aeb987 < f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d`\n- `Linux 41c5b269af8b1f0bffcab7766a793f294ae6764e`\n- `Linux 27e795afba0018b0ea9460dbad4bd706d1ba5ee0`\n- `Linux >= 6.12.95 < 6.12.109`\n- `Linux >= 6.18.38 < 6.18.50`\n- `Linux >= 6.6.144 < 6.7`\n- `Linux >= 7.0.4 < 7.1`\n- `Linux 7.1`\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.\n\n## Vendor advisories\n\n- **Red Hat VEX** · Moderate · affected: Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 9, Red Hat OpenShift Container Platform 4 · no fix planned: Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 9, Red Hat OpenShift Container Platform 4 · updated 2026-09-21 · [vex](https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-89768.json)","depth":"sunlit","depthScore":30,"depthScoreParts":{"impact":30.3,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[{"seq":208930,"id":"CVE-2026-89768","ts":1790062293417,"field":"cvss","old":"2.3","new":"5.5"},{"seq":208929,"id":"CVE-2026-89768","ts":1790062293417,"field":"severity","old":"low","new":"medium"},{"seq":204055,"id":"CVE-2026-89768","ts":1789490231221,"field":"cvss","old":null,"new":"2.3"},{"seq":204054,"id":"CVE-2026-89768","ts":1789490231221,"field":"severity","old":"none","new":"low"},{"seq":147644,"id":"CVE-2026-89768","ts":1789270211716,"field":"cvss","old":null,"new":"2.3"},{"seq":147643,"id":"CVE-2026-89768","ts":1789270211716,"field":"severity","old":"none","new":"low"},{"seq":109388,"id":"CVE-2026-89768","ts":1789183731712,"field":"cvss","old":null,"new":"2.3"},{"seq":109387,"id":"CVE-2026-89768","ts":1789183731712,"field":"severity","old":"none","new":"low"}]}