<?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>Fri, 02 Oct 2026 18:16:09 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-64551</title>
      <link>https://vulnerability.circl.lu/vuln/bell-cve-2026-64551</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-64551</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0981 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
      <link>https://vulnerability.circl.lu/vuln/certfr-2026-avi-0981</link>
      <description>certfr-2026-avi-0981</description>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/certfr-2026-avi-0981</guid>
    </item>
    <item>
      <title>fkie_cve-2026-64551</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-64551</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;sctp: validate STALE_COOKIE cause length before reading staleness&lt;/p&gt;
&lt;p&gt;When an ERROR chunk with a STALE_COOKIE cause is received in the
COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure
of Staleness that follows the cause header:&lt;/p&gt;
&lt;p&gt;err   = (struct sctp_errhdr *)(chunk-&amp;gt;skb-&amp;gt;data);
	stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));&lt;/p&gt;
&lt;p&gt;err is the first cause in the chunk, not the STALE_COOKIE cause that
caused the dispatch, and nothing guarantees the staleness field is
present. sctp_walk_errors() only requires a cause to be as long as the
4-byte header, so for a STALE_COOKIE cause of length 4 the read runs
past the cause, and for a minimal ERROR chunk past skb-&amp;gt;tail. The value
is echoed to the peer in the Cookie Preservative of the reply INIT,
leaking uninitialized memory.&lt;/p&gt;
&lt;p&gt;sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so
check its length there and pass it to sctp_sf_do_5_2_6_stale(), which
reads that cause instead of the first one. A STALE_COOKIE cause too
short to hold the staleness field is discarded.&lt;/p&gt;
&lt;p&gt;The read is reachable by any peer that can drive an association into
COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket
in a user and network namespace.&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;sctp: validate STALE_COOKIE cause length before reading staleness&lt;/p&gt;
&lt;p&gt;When an ERROR chunk with a STALE_COOKIE cause is received in the
COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure
of Staleness that follows the cause header:&lt;/p&gt;
&lt;p&gt;err   = (struct sctp_errhdr *)(chunk-&amp;gt;skb-&amp;gt;data);
	stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));&lt;/p&gt;
&lt;p&gt;err is the first cause in the chunk, not the STALE_COOKIE cause that
caused the dispatch, and nothing guarantees the staleness field is
present. sctp_walk_errors() only requires a cause to be as long as the
4-byte header, so for a STALE_COOKIE cause of length 4 the read runs
past the cause, and for a minimal ERROR chunk past skb-&amp;gt;tail. The value
is echoed to the peer in the Cookie Preservative of the reply INIT,
leaking uninitialized memory.&lt;/p&gt;
&lt;p&gt;sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so
check its length there and pass it to sctp_sf_do_5_2_6_stale(), which
reads that cause instead of the first one. A STALE_COOKIE cause too
short to hold the staleness field is discarded.&lt;/p&gt;
&lt;p&gt;The read is reachable by any peer that can drive an association into
COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket
in a user and network namespace.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-64551</guid>
    </item>
    <item>
      <title>GHSA-m58p-8fjh-3whj</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-m58p-8fjh-3whj</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;sctp: validate STALE_COOKIE cause length before reading staleness&lt;/p&gt;
&lt;p&gt;When an ERROR chunk with a STALE_COOKIE cause is received in the
COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure
of Staleness that follows the cause header:&lt;/p&gt;
&lt;p&gt;err   = (struct sctp_errhdr *)(chunk-&amp;gt;skb-&amp;gt;data);
	stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));&lt;/p&gt;
&lt;p&gt;err is the first cause in the chunk, not the STALE_COOKIE cause that
caused the dispatch, and nothing guarantees the staleness field is
present. sctp_walk_errors() only requires a cause to be as long as the
4-byte header, so for a STALE_COOKIE cause of length 4 the read runs
past the cause, and for a minimal ERROR chunk past skb-&amp;gt;tail. The value
is echoed to the peer in the Cookie Preservative of the reply INIT,
leaking uninitialized memory.&lt;/p&gt;
&lt;p&gt;sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so
check its length there and pass it to sctp_sf_do_5_2_6_stale(), which
reads that cause instead of the first one. A STALE_COOKIE cause too
short to hold the staleness field is discarded.&lt;/p&gt;
&lt;p&gt;The read is reachable by any peer that can drive an association into
COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket
in a user and network namespace.&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;sctp: validate STALE_COOKIE cause length before reading staleness&lt;/p&gt;
&lt;p&gt;When an ERROR chunk with a STALE_COOKIE cause is received in the
COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure
of Staleness that follows the cause header:&lt;/p&gt;
&lt;p&gt;err   = (struct sctp_errhdr *)(chunk-&amp;gt;skb-&amp;gt;data);
	stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));&lt;/p&gt;
&lt;p&gt;err is the first cause in the chunk, not the STALE_COOKIE cause that
caused the dispatch, and nothing guarantees the staleness field is
present. sctp_walk_errors() only requires a cause to be as long as the
4-byte header, so for a STALE_COOKIE cause of length 4 the read runs
past the cause, and for a minimal ERROR chunk past skb-&amp;gt;tail. The value
is echoed to the peer in the Cookie Preservative of the reply INIT,
leaking uninitialized memory.&lt;/p&gt;
&lt;p&gt;sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so
check its length there and pass it to sctp_sf_do_5_2_6_stale(), which
reads that cause instead of the first one. A STALE_COOKIE cause too
short to hold the staleness field is discarded.&lt;/p&gt;
&lt;p&gt;The read is reachable by any peer that can drive an association into
COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket
in a user and network namespace.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-m58p-8fjh-3whj</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>openSUSE-SU-2026:11476-1 — kernel-devel-7.1.7-1.1 on GA media</title>
      <link>https://vulnerability.circl.lu/vuln/opensuse-su-2026:11476-1</link>
      <description>&lt;p&gt;kernel-devel-7.1.7-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.1.7-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/opensuse-su-2026:11476-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:23477-1 — Security update for the Linux Kernel</title>
      <link>https://vulnerability.circl.lu/vuln/suse-su-2026:23477-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/suse-su-2026:23477-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-64551</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-64551</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: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: 	err   = (struct sctp_errhdr *)(chunk-&amp;gt;skb-&amp;gt;data); 	stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb-&amp;gt;tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.&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: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: 	err   = (struct sctp_errhdr *)(chunk-&amp;gt;skb-&amp;gt;data); 	stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb-&amp;gt;tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-64551</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2536 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://vulnerability.circl.lu/vuln/wid-sec-w-2026-2536</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um den Speicher zu beschädigen, vertrauliche Informationen offenzulegen, Daten zu manipulieren oder einen Denial-of-Service-Zustand zu verursachen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um den Speicher zu beschädigen, vertrauliche Informationen offenzulegen, Daten zu manipulieren oder einen Denial-of-Service-Zustand zu verursachen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/wid-sec-w-2026-2536</guid>
    </item>
  </channel>
</rss>
