<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 06 Oct 2026 16:27:02 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-64057 — afs: Fix the locking used by afs_get_link()</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-64057</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;afs: Fix the locking used by afs_get_link()&lt;/p&gt;
&lt;p&gt;The afs filesystem in the kernel doesn&amp;#39;t do locking correctly for symbolic
links.  There are a number of problems:&lt;/p&gt;
&lt;p&gt;(1) It doesn&amp;#39;t do any locking around afs_read_single() to prevent races
     between multiple -&amp;gt;get_link() calls, thereby allowing the possibility
     of leaks.&lt;/p&gt;
&lt;p&gt;(2) It doesn&amp;#39;t use RCU barriering when accessing the buffer pointers
     during RCU pathwalk.&lt;/p&gt;
&lt;p&gt;(3) It can race with another thread updating the contents of the symlink
     if a third party updated it on the server.&lt;/p&gt;
&lt;p&gt;Fix this by the following means:&lt;/p&gt;
&lt;p&gt;(0) Move symlink handling into its own file as this makes it more
     complicated.&lt;/p&gt;
&lt;p&gt;(1) Take the validate_lock around afs_read_single() to prevent races
     between multiple -&amp;gt;get_link() calls.&lt;/p&gt;
&lt;p&gt;(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&amp;#39;d and save quite a bit of memory.  It also needs a refcount
     for non-RCU pathwalk.&lt;/p&gt;
&lt;p&gt;(3) Split the symlink read and write-to-cache routines in afs from those
     for directories.&lt;/p&gt;
&lt;p&gt;(4) Discard the I/O buffer as soon as the write-to-cache completes as this
     is a full page (plus a folio_queue).&lt;/p&gt;
&lt;p&gt;(5) If there&amp;#39;s no cache, discard the I/O buffer immediately after reading
     and copying if there is no cache.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;afs: Fix the locking used by afs_get_link()&lt;/p&gt;
&lt;p&gt;The afs filesystem in the kernel doesn&amp;#39;t do locking correctly for symbolic
links.  There are a number of problems:&lt;/p&gt;
&lt;p&gt;(1) It doesn&amp;#39;t do any locking around afs_read_single() to prevent races
     between multiple -&amp;gt;get_link() calls, thereby allowing the possibility
     of leaks.&lt;/p&gt;
&lt;p&gt;(2) It doesn&amp;#39;t use RCU barriering when accessing the buffer pointers
     during RCU pathwalk.&lt;/p&gt;
&lt;p&gt;(3) It can race with another thread updating the contents of the symlink
     if a third party updated it on the server.&lt;/p&gt;
&lt;p&gt;Fix this by the following means:&lt;/p&gt;
&lt;p&gt;(0) Move symlink handling into its own file as this makes it more
     complicated.&lt;/p&gt;
&lt;p&gt;(1) Take the validate_lock around afs_read_single() to prevent races
     between multiple -&amp;gt;get_link() calls.&lt;/p&gt;
&lt;p&gt;(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&amp;#39;d and save quite a bit of memory.  It also needs a refcount
     for non-RCU pathwalk.&lt;/p&gt;
&lt;p&gt;(3) Split the symlink read and write-to-cache routines in afs from those
     for directories.&lt;/p&gt;
&lt;p&gt;(4) Discard the I/O buffer as soon as the write-to-cache completes as this
     is a full page (plus a folio_queue).&lt;/p&gt;
&lt;p&gt;(5) If there&amp;#39;s no cache, discard the I/O buffer immediately after reading
     and copying if there is no cache.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-64057</guid>
    </item>
  </channel>
</rss>
