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… (CVE-2026-64057)
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.
AI Analysis
Technical Summary
The Linux kernel's AFS filesystem did not correctly implement locking around symbolic link operations in afs_get_link(). Specifically, it lacked locking around afs_read_single(), did not use RCU barriers when accessing buffer pointers during RCU pathwalk, and could race with concurrent updates to symlink contents. The patch addresses these by introducing validate_lock around afs_read_single(), maintaining a separate copy of symlink contents with proper reference counting and RCU handling, splitting symlink read/write cache routines from directory routines, and promptly discarding I/O buffers to prevent stale data retention.
Potential Impact
The vulnerability could lead to race conditions and memory leaks when multiple threads access or update symbolic links concurrently in the AFS filesystem. This may affect kernel stability or correctness of symlink handling, though no known exploits in the wild have been reported.
Mitigation Recommendations
A fix has been implemented in the Linux kernel to address the locking issues in the AFS filesystem's symbolic link handling. Users should update to a kernel version that includes this patch once available. Patch status is not explicitly confirmed; check the vendor or kernel mailing lists for the specific fixed version and apply the official update accordingly.
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… (CVE-2026-64057)
Description
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.
CVSS v3.1
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel's AFS filesystem did not correctly implement locking around symbolic link operations in afs_get_link(). Specifically, it lacked locking around afs_read_single(), did not use RCU barriers when accessing buffer pointers during RCU pathwalk, and could race with concurrent updates to symlink contents. The patch addresses these by introducing validate_lock around afs_read_single(), maintaining a separate copy of symlink contents with proper reference counting and RCU handling, splitting symlink read/write cache routines from directory routines, and promptly discarding I/O buffers to prevent stale data retention.
Potential Impact
The vulnerability could lead to race conditions and memory leaks when multiple threads access or update symbolic links concurrently in the AFS filesystem. This may affect kernel stability or correctness of symlink handling, though no known exploits in the wild have been reported.
Mitigation Recommendations
A fix has been implemented in the Linux kernel to address the locking issues in the AFS filesystem's symbolic link handling. Users should update to a kernel version that includes this patch once available. Patch status is not explicitly confirmed; check the vendor or kernel mailing lists for the specific fixed version and apply the official update accordingly.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-8264-g9fh-vx2h
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-64057"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a5d27a92a4a8d598912cedc
Added to database: 07/19/2026, 19:38:17 UTC
Last enriched: 07/19/2026, 19:56:16 UTC
Last updated: 07/20/2026, 19:41:22 UTC
Views: 12
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.