The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2026-89768)

Note that Nessus relies on the presence of the package as reported by the vendor.

Detections

Analytics

Linux Distros Unpatched Vulnerability : CVE-2026-89768

low Nessus Plugin ID 345263

Version 1.10

Version 1.9

Version 1.8

Version 1.7

Version 1.6

Version 1.5

Version 1.2

Version 1.1

Version 1.10 Nov 13, 2026, 4:53 PM Detection (updated detection logic) Plugin metadata Plugin Feed: 202611131653
Version 1.9 Nov 12, 2026, 7:08 AM Detection (updated detection logic) Plugin metadata Plugin Feed: 202611120708
Version 1.8 Nov 6, 2026, 2:22 PM Detection (updated detection logic) Plugin metadata Plugin Feed: 202611061422
Version 1.7 Nov 4, 2026, 12:13 PM Detection (updated detection logic) Plugin metadata Plugin Feed: 202611041213
Version 1.6 Oct 18, 2026, 5:28 AM Detection (updated detection logic) Plugin Feed: 202610180528
Version 1.5 Sep 30, 2026, 1:44 AM Detection (updated detection logic) Plugin metadata Plugin Feed: 202609300144
Version 1.2 Sep 14, 2026, 6:39 PM CVSS metrics ("CVSSv2 score" set to 1.5) CVSS metrics ("CVSSv2 vector" set to "CVSS2#AV:L/AC:M/Au:S/C:P/I:N/A:N") Detection (updated detection logic) Plugin metadata Plugin Feed: 202609141839
Version 1.1 Sep 12, 2026, 9:05 PM New Plugin Feed: 202609122105