<?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>Wed, 30 Sep 2026 13:30:18 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-97583</title>
      <link>https://vulnerability.circl.lu/vuln/bell-cve-2026-97583</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/bell-cve-2026-97583</guid>
    </item>
    <item>
      <title>fkie_cve-2026-97583</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-97583</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;afs: Clear stale peer app data after address list changes&lt;/p&gt;
&lt;p&gt;afs_fs_probe_fileserver() fetches the current endpoint state under
server-&amp;gt;fs_lock, but leaves old_alist as NULL.  Consequently,
afs_set_peer_appdata() treats every address list replacement as initial
setup and only binds the new peers; it never unbinds peers removed from
the old list.&lt;/p&gt;
&lt;p&gt;An address refresh can therefore proceed as follows.  CPU 0 replaces
server S&amp;#39;s list and drops Pold without clearing Pold-&amp;gt;app_data.  The
server destroyer then clears only S&amp;#39;s current peers and lets S reach its
RCU callback.  After the callback frees S, CPU 1 handles a callback
through an RxRPC connection that still pins Pold, reads Pold-&amp;gt;app_data,
and calls afs_use_server() on the freed object.&lt;/p&gt;
&lt;p&gt;KASAN reported:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in afs_find_server+0x3c/0xa0
  Read of size 4 at addr ffff8881013e1af0 by task krxrpcio/7001/74
  Call Trace:
   afs_find_server+0x3c/0xa0
   afs_rx_new_call+0x15c/0x390
   rxrpc_new_incoming_call+0x97c/0x1730
   rxrpc_input_packet.constprop.0+0xd03/0xec0
   rxrpc_io_thread+0x967/0x1640
  Allocated by task 93:
   afs_lookup_server+0x1a7/0x14c0
   afs_alloc_server_list+0x43f/0xb60
   afs_create_volume+0x923/0x1490
   afs_get_tree+0x1c6/0x10a0
  Freed by task 0:
   kfree+0x131/0x3c0
   rcu_core+0x50a/0x1850
  Last potentially related work creation:
   __call_rcu_common.constprop.0+0x71/0xa10
   afs_put_server+0x213/0x2b0&lt;/p&gt;
&lt;p&gt;Pres…&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: Clear stale peer app data after address list changes&lt;/p&gt;
&lt;p&gt;afs_fs_probe_fileserver() fetches the current endpoint state under
server-&amp;gt;fs_lock, but leaves old_alist as NULL.  Consequently,
afs_set_peer_appdata() treats every address list replacement as initial
setup and only binds the new peers; it never unbinds peers removed from
the old list.&lt;/p&gt;
&lt;p&gt;An address refresh can therefore proceed as follows.  CPU 0 replaces
server S&amp;#39;s list and drops Pold without clearing Pold-&amp;gt;app_data.  The
server destroyer then clears only S&amp;#39;s current peers and lets S reach its
RCU callback.  After the callback frees S, CPU 1 handles a callback
through an RxRPC connection that still pins Pold, reads Pold-&amp;gt;app_data,
and calls afs_use_server() on the freed object.&lt;/p&gt;
&lt;p&gt;KASAN reported:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in afs_find_server+0x3c/0xa0
  Read of size 4 at addr ffff8881013e1af0 by task krxrpcio/7001/74
  Call Trace:
   afs_find_server+0x3c/0xa0
   afs_rx_new_call+0x15c/0x390
   rxrpc_new_incoming_call+0x97c/0x1730
   rxrpc_input_packet.constprop.0+0xd03/0xec0
   rxrpc_io_thread+0x967/0x1640
  Allocated by task 93:
   afs_lookup_server+0x1a7/0x14c0
   afs_alloc_server_list+0x43f/0xb60
   afs_create_volume+0x923/0x1490
   afs_get_tree+0x1c6/0x10a0
  Freed by task 0:
   kfree+0x131/0x3c0
   rcu_core+0x50a/0x1850
  Last potentially related work creation:
   __call_rcu_common.constprop.0+0x71/0xa10
   afs_put_server+0x213/0x2b0&lt;/p&gt;
&lt;p&gt;Pres…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-97583</guid>
    </item>
    <item>
      <title>GHSA-477v-9mhf-xmx8</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-477v-9mhf-xmx8</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;afs: Clear stale peer app data after address list changes&lt;/p&gt;
&lt;p&gt;afs_fs_probe_fileserver() fetches the current endpoint state under
server-&amp;gt;fs_lock, but leaves old_alist as NULL.  Consequently,
afs_set_peer_appdata() treats every address list replacement as initial
setup and only binds the new peers; it never unbinds peers removed from
the old list.&lt;/p&gt;
&lt;p&gt;An address refresh can therefore proceed as follows.  CPU 0 replaces
server S&amp;#39;s list and drops Pold without clearing Pold-&amp;gt;app_data.  The
server destroyer then clears only S&amp;#39;s current peers and lets S reach its
RCU callback.  After the callback frees S, CPU 1 handles a callback
through an RxRPC connection that still pins Pold, reads Pold-&amp;gt;app_data,
and calls afs_use_server() on the freed object.&lt;/p&gt;
&lt;p&gt;KASAN reported:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in afs_find_server+0x3c/0xa0
  Read of size 4 at addr ffff8881013e1af0 by task krxrpcio/7001/74
  Call Trace:
   afs_find_server+0x3c/0xa0
   afs_rx_new_call+0x15c/0x390
   rxrpc_new_incoming_call+0x97c/0x1730
   rxrpc_input_packet.constprop.0+0xd03/0xec0
   rxrpc_io_thread+0x967/0x1640
  Allocated by task 93:
   afs_lookup_server+0x1a7/0x14c0
   afs_alloc_server_list+0x43f/0xb60
   afs_create_volume+0x923/0x1490
   afs_get_tree+0x1c6/0x10a0
  Freed by task 0:
   kfree+0x131/0x3c0
   rcu_core+0x50a/0x1850
  Last potentially related work creation:
   __call_rcu_common.constprop.0+0x71/0xa10
   afs_put_server+0x213/0x2b0&lt;/p&gt;
&lt;p&gt;Pres…&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: Clear stale peer app data after address list changes&lt;/p&gt;
&lt;p&gt;afs_fs_probe_fileserver() fetches the current endpoint state under
server-&amp;gt;fs_lock, but leaves old_alist as NULL.  Consequently,
afs_set_peer_appdata() treats every address list replacement as initial
setup and only binds the new peers; it never unbinds peers removed from
the old list.&lt;/p&gt;
&lt;p&gt;An address refresh can therefore proceed as follows.  CPU 0 replaces
server S&amp;#39;s list and drops Pold without clearing Pold-&amp;gt;app_data.  The
server destroyer then clears only S&amp;#39;s current peers and lets S reach its
RCU callback.  After the callback frees S, CPU 1 handles a callback
through an RxRPC connection that still pins Pold, reads Pold-&amp;gt;app_data,
and calls afs_use_server() on the freed object.&lt;/p&gt;
&lt;p&gt;KASAN reported:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in afs_find_server+0x3c/0xa0
  Read of size 4 at addr ffff8881013e1af0 by task krxrpcio/7001/74
  Call Trace:
   afs_find_server+0x3c/0xa0
   afs_rx_new_call+0x15c/0x390
   rxrpc_new_incoming_call+0x97c/0x1730
   rxrpc_input_packet.constprop.0+0xd03/0xec0
   rxrpc_io_thread+0x967/0x1640
  Allocated by task 93:
   afs_lookup_server+0x1a7/0x14c0
   afs_alloc_server_list+0x43f/0xb60
   afs_create_volume+0x923/0x1490
   afs_get_tree+0x1c6/0x10a0
  Freed by task 0:
   kfree+0x131/0x3c0
   rcu_core+0x50a/0x1850
  Last potentially related work creation:
   __call_rcu_common.constprop.0+0x71/0xa10
   afs_put_server+0x213/0x2b0&lt;/p&gt;
&lt;p&gt;Pres…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-477v-9mhf-xmx8</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-97583</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-97583</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: afs: Clear stale peer app data after address list changes afs_fs_probe_fileserver() fetches the current endpoint state under server-&amp;gt;fs_lock, but leaves old_alist as NULL.  Consequently, afs_set_peer_appdata() treats every address list replacement as initial setup and only binds the new peers; it never unbinds peers removed from the old list. An address refresh can therefore proceed as follows.  CPU 0 replaces server S&amp;#39;s list and drops Pold without clearing Pold-&amp;gt;app_data.  The server destroyer then clears only S&amp;#39;s current peers and lets S reach its RCU callback.  After the callback frees S, CPU 1 handles a callback through an RxRPC connection that still pins Pold, reads Pold-&amp;gt;app_data, and calls afs_use_server() on the freed object. KASAN reported:   BUG: KASAN: slab-use-after-free in afs_find_server+0x3c/0xa0   Read of size 4 at addr ffff8881013e1af0 by task krxrpcio/7001/74   Call Trace:    afs_find_server+0x3c/0xa0    afs_rx_new_call+0x15c/0x390    rxrpc_new_incoming_call+0x97c/0x1730    rxrpc_input_packet.constprop.0+0xd03/0xec0    rxrpc_io_thread+0x967/0x1640   Allocated by task 93:    afs_lookup_server+0x1a7/0x14c0    afs_alloc_server_list+0x43f/0xb60    afs_create_volume+0x923/0x1490    afs_get_tree+0x1c6/0x10a0   Freed by task 0:    kfree+0x131/0x3c0    rcu_core+0x50a/0x1850   Last potentially related work creation:    __call_rcu_common.constprop.0+0x71/0xa10    afs_put_server+0x213/0x2b0 Preserve o…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: afs: Clear stale peer app data after address list changes afs_fs_probe_fileserver() fetches the current endpoint state under server-&amp;gt;fs_lock, but leaves old_alist as NULL.  Consequently, afs_set_peer_appdata() treats every address list replacement as initial setup and only binds the new peers; it never unbinds peers removed from the old list. An address refresh can therefore proceed as follows.  CPU 0 replaces server S&amp;#39;s list and drops Pold without clearing Pold-&amp;gt;app_data.  The server destroyer then clears only S&amp;#39;s current peers and lets S reach its RCU callback.  After the callback frees S, CPU 1 handles a callback through an RxRPC connection that still pins Pold, reads Pold-&amp;gt;app_data, and calls afs_use_server() on the freed object. KASAN reported:   BUG: KASAN: slab-use-after-free in afs_find_server+0x3c/0xa0   Read of size 4 at addr ffff8881013e1af0 by task krxrpcio/7001/74   Call Trace:    afs_find_server+0x3c/0xa0    afs_rx_new_call+0x15c/0x390    rxrpc_new_incoming_call+0x97c/0x1730    rxrpc_input_packet.constprop.0+0xd03/0xec0    rxrpc_io_thread+0x967/0x1640   Allocated by task 93:    afs_lookup_server+0x1a7/0x14c0    afs_alloc_server_list+0x43f/0xb60    afs_create_volume+0x923/0x1490    afs_get_tree+0x1c6/0x10a0   Freed by task 0:    kfree+0x131/0x3c0    rcu_core+0x50a/0x1850   Last potentially related work creation:    __call_rcu_common.constprop.0+0x71/0xa10    afs_put_server+0x213/0x2b0 Preserve o…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-97583</guid>
    </item>
  </channel>
</rss>
