{"api_version":"1","generated_at":"2026-09-11T23:53:30+00:00","cve":"CVE-2026-89768","urls":{"html":"https://cve.report/CVE-2026-89768","api":"https://cve.report/api/cve/CVE-2026-89768.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-89768","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-89768"},"summary":{"title":"fs: fix user path of nested backing files","description":"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 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.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-11 20:20:08","updated_at":"2026-09-11 20:20:08"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d","name":"https://git.kernel.org/stable/c/f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/88c927a63dc717b6d46b20fe13ea713916e49089","name":"https://git.kernel.org/stable/c/88c927a63dc717b6d46b20fe13ea713916e49089","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/a35cc21355734e1acb89973d9be90ca8e4c3ed2f","name":"https://git.kernel.org/stable/c/a35cc21355734e1acb89973d9be90ca8e4c3ed2f","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/c03114634d342648bd34910aa8fb88007e92cc3c","name":"https://git.kernel.org/stable/c/c03114634d342648bd34910aa8fb88007e92cc3c","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-89768","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89768","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 5b6aa9a843205da92d860e5011a7b29062a76b8f 88c927a63dc717b6d46b20fe13ea713916e49089 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 5dfcb15974e7d0f96aca278dd9f1b85df91523ef c03114634d342648bd34910aa8fb88007e92cc3c git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6af36aeb147a06dea47c49859cd6ca5659aeb987 a35cc21355734e1acb89973d9be90ca8e4c3ed2f git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6af36aeb147a06dea47c49859cd6ca5659aeb987 f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 41c5b269af8b1f0bffcab7766a793f294ae6764e git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 27e795afba0018b0ea9460dbad4bd706d1ba5ee0 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.12.95 6.12.109 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.18.38 6.18.50 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.6.144 6.7 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 7.0.4 7.1 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 7.1","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.1 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.109 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.50 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.4 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3-rc1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["fs/backing-file.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"88c927a63dc717b6d46b20fe13ea713916e49089","status":"affected","version":"5b6aa9a843205da92d860e5011a7b29062a76b8f","versionType":"git"},{"lessThan":"c03114634d342648bd34910aa8fb88007e92cc3c","status":"affected","version":"5dfcb15974e7d0f96aca278dd9f1b85df91523ef","versionType":"git"},{"lessThan":"a35cc21355734e1acb89973d9be90ca8e4c3ed2f","status":"affected","version":"6af36aeb147a06dea47c49859cd6ca5659aeb987","versionType":"git"},{"lessThan":"f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d","status":"affected","version":"6af36aeb147a06dea47c49859cd6ca5659aeb987","versionType":"git"},{"status":"affected","version":"41c5b269af8b1f0bffcab7766a793f294ae6764e","versionType":"git"},{"status":"affected","version":"27e795afba0018b0ea9460dbad4bd706d1ba5ee0","versionType":"git"},{"lessThan":"6.12.109","status":"affected","version":"6.12.95","versionType":"semver"},{"lessThan":"6.18.50","status":"affected","version":"6.18.38","versionType":"semver"},{"lessThan":"6.7","status":"affected","version":"6.6.144","versionType":"semver"},{"lessThan":"7.1","status":"affected","version":"7.0.4","versionType":"semver"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["fs/backing-file.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"7.1"},{"lessThan":"7.1","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.109","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.50","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.4","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3-rc1","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.109","versionStartIncluding":"6.12.95","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.50","versionStartIncluding":"6.18.38","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.4","versionStartIncluding":"7.1","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3-rc1","versionStartIncluding":"7.1","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.6.144","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"7.0.4","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"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 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."}],"providerMetadata":{"dateUpdated":"2026-09-11T19:47:08.119Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"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"}],"title":"fs: fix user path of nested backing files","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-89768","datePublished":"2026-09-11T19:47:08.119Z","dateReserved":"2026-09-11T19:38:34.764Z","dateUpdated":"2026-09-11T19:47:08.119Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-11 20:20:08","lastModifiedDate":"2026-09-11 20:20:08","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"89768","Ordinal":"1","Title":"fs: fix user path of nested backing files","CVE":"CVE-2026-89768","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"89768","Ordinal":"1","NoteData":"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 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.","Type":"Description","Title":"fs: fix user path of nested backing files"}]}}}