<?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://cve.radiocsirt.org</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>Fri, 02 Oct 2026 17:34:04 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-64057</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-64057</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-64057</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0926 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0926</link>
      <description>certfr-2026-avi-0926</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0926</guid>
    </item>
    <item>
      <title>EUVD-2026-348380</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-348380</link>
      <description>EUVD-2026-348380</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-348380</guid>
    </item>
    <item>
      <title>fkie_cve-2026-64057</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-64057</link>
      <description>&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;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://cve.radiocsirt.org/vuln/fkie_cve-2026-64057</guid>
    </item>
    <item>
      <title>GHSA-8264-g9fh-vx2h</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-8264-g9fh-vx2h</link>
      <description>&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;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://cve.radiocsirt.org/vuln/ghsa-8264-g9fh-vx2h</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-64057</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-64057</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 118 more&lt;/p&gt;
&lt;p&gt;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&amp;#39;t do locking correctly for symbolic links.  There are a number of problems:  (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.  (2) It doesn&amp;#39;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 -&amp;gt;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&amp;#39;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&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; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 118 more&lt;/p&gt;
&lt;p&gt;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&amp;#39;t do locking correctly for symbolic links.  There are a number of problems:  (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.  (2) It doesn&amp;#39;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 -&amp;gt;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&amp;#39;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&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://cve.radiocsirt.org/vuln/ubuntu-cve-2026-64057</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2403 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2403</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen oder vertrauliche Informationen offenzulegen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen oder vertrauliche Informationen offenzulegen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2403</guid>
    </item>
  </channel>
</rss>
