<?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>Thu, 01 Oct 2026 16:15:40 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-93103</title>
      <link>https://vulnerability.circl.lu/vuln/bell-cve-2026-93103</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, 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:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/bell-cve-2026-93103</guid>
    </item>
    <item>
      <title>fkie_cve-2026-93103</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-93103</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;RDMA/hfi1: Preserve unit 0 on allocation failure&lt;/p&gt;
&lt;p&gt;hfi1_free_devdata() assumes that the device was inserted into the unit
table and unconditionally erases dd-&amp;gt;unit. If xa_alloc_irq() fails, the
zero-initialized unit remains zero, so full cleanup can remove an
unrelated device from index 0.&lt;/p&gt;
&lt;p&gt;Release only the rdmavt allocation and return immediately while the unit
table has not acquired the device.&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;RDMA/hfi1: Preserve unit 0 on allocation failure&lt;/p&gt;
&lt;p&gt;hfi1_free_devdata() assumes that the device was inserted into the unit
table and unconditionally erases dd-&amp;gt;unit. If xa_alloc_irq() fails, the
zero-initialized unit remains zero, so full cleanup can remove an
unrelated device from index 0.&lt;/p&gt;
&lt;p&gt;Release only the rdmavt allocation and return immediately while the unit
table has not acquired the device.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-93103</guid>
    </item>
    <item>
      <title>GHSA-jjcw-q5gq-x45h</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-jjcw-q5gq-x45h</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;RDMA/hfi1: Preserve unit 0 on allocation failure&lt;/p&gt;
&lt;p&gt;hfi1_free_devdata() assumes that the device was inserted into the unit
table and unconditionally erases dd-&amp;gt;unit. If xa_alloc_irq() fails, the
zero-initialized unit remains zero, so full cleanup can remove an
unrelated device from index 0.&lt;/p&gt;
&lt;p&gt;Release only the rdmavt allocation and return immediately while the unit
table has not acquired the device.&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;RDMA/hfi1: Preserve unit 0 on allocation failure&lt;/p&gt;
&lt;p&gt;hfi1_free_devdata() assumes that the device was inserted into the unit
table and unconditionally erases dd-&amp;gt;unit. If xa_alloc_irq() fails, the
zero-initialized unit remains zero, so full cleanup can remove an
unrelated device from index 0.&lt;/p&gt;
&lt;p&gt;Release only the rdmavt allocation and return immediately while the unit
table has not acquired the device.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-jjcw-q5gq-x45h</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-93103 — RDMA/hfi1: Preserve unit 0 on allocation failure</title>
      <link>https://vulnerability.circl.lu/vuln/msrc_cve-2026-93103</link>
      <description>msrc_CVE-2026-93103</description>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/msrc_cve-2026-93103</guid>
    </item>
    <item>
      <title>OESA-2026-4185 — kernel security update</title>
      <link>https://vulnerability.circl.lu/vuln/oesa-2026-4185</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;netfilter: ipset: fix race between dump and ip_set_list resize&lt;/p&gt;
&lt;p&gt;The release path of ip_set_dump_do() and ip_set_dump_done() read
inst-&amp;amp;gt;ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw()
of the array pointer. These run from netlink_recvmsg() without the nfnl
mutex and without an RCU read-side critical section.&lt;/p&gt;
&lt;p&gt;A concurrent ip_set_create() can grow the array: it publishes the new
array, calls synchronize_net() and then kvfree()s the old one. Since the
dump paths read the array outside any RCU reader, synchronize_net() does
not wait for them and the old array can be freed while they still index
into it, causing a use-after-free.&lt;/p&gt;
&lt;p&gt;The dumped set itself stays pinned via set-&amp;amp;gt;ref_netlink, so only the
array load needs protecting. Take rcu_read_lock() around it, matching
ip_set_get_byname() and __ip_set_put_byindex().&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)
  Read of size 8 at addr ffff88800b5c4018 by task exploit/150
  Call Trace:
   ...
   kasan_report (mm/kasan/report.c:595)
   ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)
   netlink_dump (net/netlink/af_netlink.c:2325)
   netlink_recvmsg (net/netlink/af_netlink.c:1976)
   sock_recvmsg (net/socket.c:1159)
   __sys_recvfrom (net/socket.c:2315)
   ...
  Oops: general protection fault, probably for non-can…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;netfilter: ipset: fix race between dump and ip_set_list resize&lt;/p&gt;
&lt;p&gt;The release path of ip_set_dump_do() and ip_set_dump_done() read
inst-&amp;amp;gt;ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw()
of the array pointer. These run from netlink_recvmsg() without the nfnl
mutex and without an RCU read-side critical section.&lt;/p&gt;
&lt;p&gt;A concurrent ip_set_create() can grow the array: it publishes the new
array, calls synchronize_net() and then kvfree()s the old one. Since the
dump paths read the array outside any RCU reader, synchronize_net() does
not wait for them and the old array can be freed while they still index
into it, causing a use-after-free.&lt;/p&gt;
&lt;p&gt;The dumped set itself stays pinned via set-&amp;amp;gt;ref_netlink, so only the
array load needs protecting. Take rcu_read_lock() around it, matching
ip_set_get_byname() and __ip_set_put_byindex().&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)
  Read of size 8 at addr ffff88800b5c4018 by task exploit/150
  Call Trace:
   ...
   kasan_report (mm/kasan/report.c:595)
   ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)
   netlink_dump (net/netlink/af_netlink.c:2325)
   netlink_recvmsg (net/netlink/af_netlink.c:1976)
   sock_recvmsg (net/socket.c:1159)
   __sys_recvfrom (net/socket.c:2315)
   ...
  Oops: general protection fault, probably for non-can…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/oesa-2026-4185</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11893-1 — kernel-devel-7.2.8-1.1 on GA media</title>
      <link>https://vulnerability.circl.lu/vuln/opensuse-su-2026:11893-1</link>
      <description>&lt;p&gt;kernel-devel-7.2.8-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.2.8-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/opensuse-su-2026:11893-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-93103</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-93103</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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 219 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Preserve unit 0 on allocation failure hfi1_free_devdata() assumes that the device was inserted into the unit table and unconditionally erases dd-&amp;gt;unit. If xa_alloc_irq() fails, the zero-initialized unit remains zero, so full cleanup can remove an unrelated device from index 0. Release only the rdmavt allocation and return immediately while the unit table has not acquired the device.&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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 219 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Preserve unit 0 on allocation failure hfi1_free_devdata() assumes that the device was inserted into the unit table and unconditionally erases dd-&amp;gt;unit. If xa_alloc_irq() fails, the zero-initialized unit remains zero, so full cleanup can remove an unrelated device from index 0. Release only the rdmavt allocation and return immediately while the unit table has not acquired the device.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-93103</guid>
    </item>
  </channel>
</rss>
