In the Linux kernel, the following vulnerability has been resolved: afs: Fix the locking used by afs_get_link() The afs filesystem in the kernel doesn't do locking correctly for symbolic links. There are a number of problems: (1) It doesn't do any locking around afs_read_single() to prevent races between multiple ->get_link() calls, thereby allowing the possibility of leaks. (2) It doesn't use RCU barriering when accessing the buffer pointers during RCU pathwalk. (3) It can race with another thread updating the contents of the symlink if a third party updated it on the server. Fix this by the following means: (0) Move symlink handling into its own file as this makes it more complicated. (1) Take the validate_lock around afs_read_single() to prevent races between multiple ->get_link() calls. (2) Keep a separate copy of the symlink contents with an rcu_head. This is always going to be a lot smaller than a page, so it can be kmalloc'd and save quite a bit of memory. It also needs a refcount for non-RCU pathwalk. (3) Split the symlink read and write-to-cache routines in afs from those for directories. (4) Discard the I/O buffer as soon as the write-to-cache completes as this is a full page (plus a folio_queue). (5) If there's no cache, discard the I/O buffer immediately after reading and copying if there is no cache.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: afs: Fix the locking used by
    afs_get_link() The afs filesystem in the kernel doesn't do locking correctly for symbolic links. There are
    a number of problems: (1) It doesn't do any locking around afs_read_single() to prevent races between
    multiple ->get_link() calls, thereby allowing the possibility of leaks. (2) It doesn't use RCU barriering
    when accessing the buffer pointers during RCU pathwalk. (3) It can race with another thread updating the
    contents of the symlink if a third party updated it on the server. Fix this by the following means: (0)
    Move symlink handling into its own file as this makes it more complicated. (1) Take the validate_lock
    around afs_read_single() to prevent races between multiple ->get_link() calls. (2) Keep a separate copy of
    the symlink contents with an rcu_head. This is always going to be a lot smaller than a page, so it can be
    kmalloc'd and save quite a bit of memory. It also needs a refcount for non-RCU pathwalk. (3) Split the
    symlink read and write-to-cache routines in afs from those for directories. (4) Discard the I/O buffer as
    soon as the write-to-cache completes as this is a full page (plus a folio_queue). (5) If there's no cache,
    discard the I/O buffer immediately after reading and copying if there is no cache. (CVE-2026-64057)

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: afs: Fix the locking used by     afs_get_link() The afs filesystem in the kernel doesn't do locking correctly for symbolic links. There are     a number of problems: (1) It doesn't do any locking around afs_read_single() to prevent races between     multiple ->get_link() calls, thereby allowing the possibility of leaks. (2) It doesn't use RCU barriering     when accessing the buffer pointers during RCU pathwalk. (3) It can race with another thread updating the     contents of the symlink if a third party updated it on the server. Fix this by the following means: (0)     Move symlink handling into its own file as this makes it more complicated. (1) Take the validate_lock     around afs_read_single() to prevent races between multiple ->get_link() calls. (2) Keep a separate copy of     the symlink contents with an rcu_head. This is always going to be a lot smaller than a page, so it can be     kmalloc'd and save quite a bit of memory. It also needs a refcount for non-RCU pathwalk. (3) Split the     symlink read and write-to-cache routines in afs from those for directories. (4) Discard the I/O buffer as     soon as the write-to-cache completes as this is a full page (plus a folio_queue). (5) If there's no cache,     discard the I/O buffer immediately after reading and copying if there is no cache. (CVE-2026-64057)

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

ID	Name	Product	Family	Type	Severity
473073	Chainguard: linux-qemu-melange: security update to 6.18.49-r2	Tenable Cloud Security	Chainguard Local Security Checks	Local	high
473073	Chainguard: linux-qemu-melange: security update to 6.18.49-r2	Tenable Self-Hosted Container Security	Chainguard Local Security Checks	Local	high
343532	Ubuntu 24.04 LTS / Pro Realtime 24.04 LTS : Linux kernel (GCP) vulnerabilities (USN-8728-1)	Nessus	Ubuntu Local Security Checks	Local	high
340681	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel (NVIDIA) vulnerabilities (USN-8663-1)	Nessus	Ubuntu Local Security Checks	Local	high
340045	Ubuntu 26.04 LTS : Linux kernel (NVIDIA BaseOS) vulnerabilities (USN-8664-1)	Nessus	Ubuntu Local Security Checks	Local	high
328006	Linux Distros Unpatched Vulnerability : CVE-2026-64057	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-64057

high

Tenable Plugins

high

high

high

high

high

high