<?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>Sun, 04 Oct 2026 09:47:48 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-74310</title>
      <link>https://vulnerability.circl.lu/vuln/bell-cve-2026-74310</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-74310</guid>
    </item>
    <item>
      <title>certfr-2026-avi-1203 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Elles permettent à un attaquant de provoq…</title>
      <link>https://vulnerability.circl.lu/vuln/certfr-2026-avi-1203</link>
      <description>certfr-2026-avi-1203</description>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/certfr-2026-avi-1203</guid>
    </item>
    <item>
      <title>fkie_cve-2026-74310</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-74310</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;vhost/net: complete zerocopy ubufs only once&lt;/p&gt;
&lt;p&gt;vhost-net initializes one ubuf_info per outstanding zerocopy TX
descriptor and hands it to the backend socket.  The networking stack may
then clone a zerocopy skb before all skb references are released.  For
example, batman-adv fragmentation reaches skb_split(), which calls
skb_zerocopy_clone() and increments the same ubuf_info refcount.&lt;/p&gt;
&lt;p&gt;vhost_zerocopy_complete() currently treats every ubuf callback as a
completed vhost descriptor.  It dereferences ubuf-&amp;gt;ctx, writes the
descriptor completion state, and drops the vhost_net_ubuf_ref even when
the callback only releases a cloned skb reference.  A backend reset can
therefore wait for and free the vhost_net_ubuf_ref while another cloned
skb still carries the same ubuf_info.  A later completion then
dereferences the freed ubufs pointer.&lt;/p&gt;
&lt;p&gt;KASAN reports the stale completion as:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0
  BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0
  vhost_zerocopy_complete
  skb_copy_ubufs
  __dev_forward_skb2
  veth_xmit&lt;/p&gt;
&lt;p&gt;The freed object was allocated from vhost_net_ioctl() while setting the
backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend
removal, while delayed skb completion still reached
vhost_zerocopy_complete().&lt;/p&gt;
&lt;p&gt;Honor the generic ubuf_info refcount before touching vhost state, and run
the vhost descriptor completion o…&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;vhost/net: complete zerocopy ubufs only once&lt;/p&gt;
&lt;p&gt;vhost-net initializes one ubuf_info per outstanding zerocopy TX
descriptor and hands it to the backend socket.  The networking stack may
then clone a zerocopy skb before all skb references are released.  For
example, batman-adv fragmentation reaches skb_split(), which calls
skb_zerocopy_clone() and increments the same ubuf_info refcount.&lt;/p&gt;
&lt;p&gt;vhost_zerocopy_complete() currently treats every ubuf callback as a
completed vhost descriptor.  It dereferences ubuf-&amp;gt;ctx, writes the
descriptor completion state, and drops the vhost_net_ubuf_ref even when
the callback only releases a cloned skb reference.  A backend reset can
therefore wait for and free the vhost_net_ubuf_ref while another cloned
skb still carries the same ubuf_info.  A later completion then
dereferences the freed ubufs pointer.&lt;/p&gt;
&lt;p&gt;KASAN reports the stale completion as:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0
  BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0
  vhost_zerocopy_complete
  skb_copy_ubufs
  __dev_forward_skb2
  veth_xmit&lt;/p&gt;
&lt;p&gt;The freed object was allocated from vhost_net_ioctl() while setting the
backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend
removal, while delayed skb completion still reached
vhost_zerocopy_complete().&lt;/p&gt;
&lt;p&gt;Honor the generic ubuf_info refcount before touching vhost state, and run
the vhost descriptor completion o…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-74310</guid>
    </item>
    <item>
      <title>GHSA-8j84-wwj3-jwr4</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-8j84-wwj3-jwr4</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;vhost/net: complete zerocopy ubufs only once&lt;/p&gt;
&lt;p&gt;vhost-net initializes one ubuf_info per outstanding zerocopy TX
descriptor and hands it to the backend socket.  The networking stack may
then clone a zerocopy skb before all skb references are released.  For
example, batman-adv fragmentation reaches skb_split(), which calls
skb_zerocopy_clone() and increments the same ubuf_info refcount.&lt;/p&gt;
&lt;p&gt;vhost_zerocopy_complete() currently treats every ubuf callback as a
completed vhost descriptor.  It dereferences ubuf-&amp;gt;ctx, writes the
descriptor completion state, and drops the vhost_net_ubuf_ref even when
the callback only releases a cloned skb reference.  A backend reset can
therefore wait for and free the vhost_net_ubuf_ref while another cloned
skb still carries the same ubuf_info.  A later completion then
dereferences the freed ubufs pointer.&lt;/p&gt;
&lt;p&gt;KASAN reports the stale completion as:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0
  BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0
  vhost_zerocopy_complete
  skb_copy_ubufs
  __dev_forward_skb2
  veth_xmit&lt;/p&gt;
&lt;p&gt;The freed object was allocated from vhost_net_ioctl() while setting the
backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend
removal, while delayed skb completion still reached
vhost_zerocopy_complete().&lt;/p&gt;
&lt;p&gt;Honor the generic ubuf_info refcount before touching vhost state, and run
the vhost descriptor completion o…&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;vhost/net: complete zerocopy ubufs only once&lt;/p&gt;
&lt;p&gt;vhost-net initializes one ubuf_info per outstanding zerocopy TX
descriptor and hands it to the backend socket.  The networking stack may
then clone a zerocopy skb before all skb references are released.  For
example, batman-adv fragmentation reaches skb_split(), which calls
skb_zerocopy_clone() and increments the same ubuf_info refcount.&lt;/p&gt;
&lt;p&gt;vhost_zerocopy_complete() currently treats every ubuf callback as a
completed vhost descriptor.  It dereferences ubuf-&amp;gt;ctx, writes the
descriptor completion state, and drops the vhost_net_ubuf_ref even when
the callback only releases a cloned skb reference.  A backend reset can
therefore wait for and free the vhost_net_ubuf_ref while another cloned
skb still carries the same ubuf_info.  A later completion then
dereferences the freed ubufs pointer.&lt;/p&gt;
&lt;p&gt;KASAN reports the stale completion as:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0
  BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0
  vhost_zerocopy_complete
  skb_copy_ubufs
  __dev_forward_skb2
  veth_xmit&lt;/p&gt;
&lt;p&gt;The freed object was allocated from vhost_net_ioctl() while setting the
backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend
removal, while delayed skb completion still reached
vhost_zerocopy_complete().&lt;/p&gt;
&lt;p&gt;Honor the generic ubuf_info refcount before touching vhost state, and run
the vhost descriptor completion o…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-8j84-wwj3-jwr4</guid>
    </item>
    <item>
      <title>OESA-2026-3705 — kernel security update</title>
      <link>https://vulnerability.circl.lu/vuln/oesa-2026-3705</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.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;ocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison&lt;/p&gt;
&lt;p&gt;The local-vs-remote region comparison loop uses &amp;amp;apos;&amp;amp;lt;=&amp;amp;apos; instead of &amp;amp;apos;&amp;amp;lt;&amp;amp;apos;,
causing it to read one entry past the valid range of qr_regions.  The
other loops in the same function correctly use &amp;amp;apos;&amp;amp;lt;&amp;amp;apos;.&lt;/p&gt;
&lt;p&gt;Fix the loop condition to use &amp;amp;apos;&amp;amp;lt;&amp;amp;apos; for consistency and correctness.(CVE-2026-53309)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ixgbevf: fix use-after-free in VEPA multicast source pruning&lt;/p&gt;
&lt;p&gt;ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF&amp;amp;apos;s
own address (VEPA multicast workaround) by freeing the skb and
continuing to the next descriptor:&lt;/p&gt;
&lt;p&gt;dev_kfree_skb_irq(skb);
    continue;&lt;/p&gt;
&lt;p&gt;The skb pointer is declared outside the while loop and persists across
iterations.  Because the continue skips the &amp;amp;quot;skb = NULL&amp;amp;quot; reset at the
bottom of the loop, the next iteration enters the &amp;amp;quot;else if (skb)&amp;amp;quot; path
and calls ixgbevf_add_rx_frag() on the freed skb, dereferencing
skb_shinfo(skb)-&amp;amp;gt;nr_frags - a use-after-free in NAPI softirq context.&lt;/p&gt;
&lt;p&gt;The sibling driver iavf already handles this correctly by nulling the
pointer before continuing.  Apply the same pattern here.&lt;/p&gt;
&lt;p&gt;I do not have ixgbevf hardware; the bug was found by static analysis
(scan_drop_continue_loops.py + semgrep drop_…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.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;ocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison&lt;/p&gt;
&lt;p&gt;The local-vs-remote region comparison loop uses &amp;amp;apos;&amp;amp;lt;=&amp;amp;apos; instead of &amp;amp;apos;&amp;amp;lt;&amp;amp;apos;,
causing it to read one entry past the valid range of qr_regions.  The
other loops in the same function correctly use &amp;amp;apos;&amp;amp;lt;&amp;amp;apos;.&lt;/p&gt;
&lt;p&gt;Fix the loop condition to use &amp;amp;apos;&amp;amp;lt;&amp;amp;apos; for consistency and correctness.(CVE-2026-53309)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ixgbevf: fix use-after-free in VEPA multicast source pruning&lt;/p&gt;
&lt;p&gt;ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF&amp;amp;apos;s
own address (VEPA multicast workaround) by freeing the skb and
continuing to the next descriptor:&lt;/p&gt;
&lt;p&gt;dev_kfree_skb_irq(skb);
    continue;&lt;/p&gt;
&lt;p&gt;The skb pointer is declared outside the while loop and persists across
iterations.  Because the continue skips the &amp;amp;quot;skb = NULL&amp;amp;quot; reset at the
bottom of the loop, the next iteration enters the &amp;amp;quot;else if (skb)&amp;amp;quot; path
and calls ixgbevf_add_rx_frag() on the freed skb, dereferencing
skb_shinfo(skb)-&amp;amp;gt;nr_frags - a use-after-free in NAPI softirq context.&lt;/p&gt;
&lt;p&gt;The sibling driver iavf already handles this correctly by nulling the
pointer before continuing.  Apply the same pattern here.&lt;/p&gt;
&lt;p&gt;I do not have ixgbevf hardware; the bug was found by static analysis
(scan_drop_continue_loops.py + semgrep drop_…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/oesa-2026-3705</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-74310</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-74310</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: vhost/net: complete zerocopy ubufs only once vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket.  The networking stack may then clone a zerocopy skb before all skb references are released.  For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor.  It dereferences ubuf-&amp;gt;ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference.  A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info.  A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as:   BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0   BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0   vhost_zerocopy_complete   skb_copy_ubufs   __dev_forward_skb2   veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for…&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: vhost/net: complete zerocopy ubufs only once vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket.  The networking stack may then clone a zerocopy skb before all skb references are released.  For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor.  It dereferences ubuf-&amp;gt;ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference.  A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info.  A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as:   BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0   BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0   vhost_zerocopy_complete   skb_copy_ubufs   __dev_forward_skb2   veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-74310</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2852 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://vulnerability.circl.lu/vuln/wid-sec-w-2026-2852</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/wid-sec-w-2026-2852</guid>
    </item>
  </channel>
</rss>
