<?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>Mon, 28 Sep 2026 16:55:22 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-97985</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-97985</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;af_unix: Update last skb marker in manage_oob().&lt;/p&gt;
&lt;p&gt;Fahad Alharbi reported that blocking recv(MSG_PEEK) could hog CPU
due to OOB skb.&lt;/p&gt;
&lt;p&gt;In the following cases, manage_oob() skips OOB skb(s) and returns
NULL for the last recv(MSG_PEEK):&lt;/p&gt;
&lt;p&gt;socketpair(AF_UNIX, SOCK_STREAM, 0, sk);&lt;/p&gt;
&lt;p&gt;1) skb -&amp;gt; OOB skb -&amp;gt; NULL
     send(sk[0], &amp;#34;ab&amp;#34;, 2, MSG_OOB);
     recv(sk[1], buf, 0, MSG_PEEK);&lt;/p&gt;
&lt;p&gt;2) skb -&amp;gt; consumed OOB skb -&amp;gt; NULL
     send(sk[0], &amp;#34;ab&amp;#34;, 2, MSG_OOB);
     recv(sk[1], buf, 1, MSG_OOB);
     recv(sk[1], buf, 0, MSG_PEEK);&lt;/p&gt;
&lt;p&gt;3) consumed OOB skb -&amp;gt; OOB skb -&amp;gt; NULL
     send(sk[0], &amp;#34;a&amp;#34;, 1, MSG_OOB);
     recv(sk[1], buf, 0, MSG_OOB);
     send(sk[0], &amp;#34;b&amp;#34;, 1, MSG_OOB);
     recv(sk[1], buf, 1, MSG_PEEK);&lt;/p&gt;
&lt;p&gt;Then, @copied is 0 in unix_stream_read_generic() (zero-length buffer,
or non-OOB skb is not yet consumed), and unix_stream_data_wait() is
called.&lt;/p&gt;
&lt;p&gt;However, it returns immediately because @last is not updated in
unix_stream_read_generic(), and the thread busy-waits for a new skb.&lt;/p&gt;
&lt;p&gt;Let&amp;#39;s update @last in manage_oob().&lt;/p&gt;
&lt;p&gt;For MSG_PEEK, @last is updated with the skipped OOB, and for the
non-peek case, @last matches the returned value (when !copied)
because OOB is unlinked.&lt;/p&gt;
&lt;p&gt;Note that manage_oob() is inlined and no stack canary is added.&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;af_unix: Update last skb marker in manage_oob().&lt;/p&gt;
&lt;p&gt;Fahad Alharbi reported that blocking recv(MSG_PEEK) could hog CPU
due to OOB skb.&lt;/p&gt;
&lt;p&gt;In the following cases, manage_oob() skips OOB skb(s) and returns
NULL for the last recv(MSG_PEEK):&lt;/p&gt;
&lt;p&gt;socketpair(AF_UNIX, SOCK_STREAM, 0, sk);&lt;/p&gt;
&lt;p&gt;1) skb -&amp;gt; OOB skb -&amp;gt; NULL
     send(sk[0], &amp;#34;ab&amp;#34;, 2, MSG_OOB);
     recv(sk[1], buf, 0, MSG_PEEK);&lt;/p&gt;
&lt;p&gt;2) skb -&amp;gt; consumed OOB skb -&amp;gt; NULL
     send(sk[0], &amp;#34;ab&amp;#34;, 2, MSG_OOB);
     recv(sk[1], buf, 1, MSG_OOB);
     recv(sk[1], buf, 0, MSG_PEEK);&lt;/p&gt;
&lt;p&gt;3) consumed OOB skb -&amp;gt; OOB skb -&amp;gt; NULL
     send(sk[0], &amp;#34;a&amp;#34;, 1, MSG_OOB);
     recv(sk[1], buf, 0, MSG_OOB);
     send(sk[0], &amp;#34;b&amp;#34;, 1, MSG_OOB);
     recv(sk[1], buf, 1, MSG_PEEK);&lt;/p&gt;
&lt;p&gt;Then, @copied is 0 in unix_stream_read_generic() (zero-length buffer,
or non-OOB skb is not yet consumed), and unix_stream_data_wait() is
called.&lt;/p&gt;
&lt;p&gt;However, it returns immediately because @last is not updated in
unix_stream_read_generic(), and the thread busy-waits for a new skb.&lt;/p&gt;
&lt;p&gt;Let&amp;#39;s update @last in manage_oob().&lt;/p&gt;
&lt;p&gt;For MSG_PEEK, @last is updated with the skipped OOB, and for the
non-peek case, @last matches the returned value (when !copied)
because OOB is unlinked.&lt;/p&gt;
&lt;p&gt;Note that manage_oob() is inlined and no stack canary is added.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-97985</guid>
    </item>
    <item>
      <title>GHSA-cq66-2f6w-rhg5</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-cq66-2f6w-rhg5</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;af_unix: Update last skb marker in manage_oob().&lt;/p&gt;
&lt;p&gt;Fahad Alharbi reported that blocking recv(MSG_PEEK) could hog CPU
due to OOB skb.&lt;/p&gt;
&lt;p&gt;In the following cases, manage_oob() skips OOB skb(s) and returns
NULL for the last recv(MSG_PEEK):&lt;/p&gt;
&lt;p&gt;socketpair(AF_UNIX, SOCK_STREAM, 0, sk);&lt;/p&gt;
&lt;p&gt;1) skb -&amp;gt; OOB skb -&amp;gt; NULL
     send(sk[0], &amp;#34;ab&amp;#34;, 2, MSG_OOB);
     recv(sk[1], buf, 0, MSG_PEEK);&lt;/p&gt;
&lt;p&gt;2) skb -&amp;gt; consumed OOB skb -&amp;gt; NULL
     send(sk[0], &amp;#34;ab&amp;#34;, 2, MSG_OOB);
     recv(sk[1], buf, 1, MSG_OOB);
     recv(sk[1], buf, 0, MSG_PEEK);&lt;/p&gt;
&lt;p&gt;3) consumed OOB skb -&amp;gt; OOB skb -&amp;gt; NULL
     send(sk[0], &amp;#34;a&amp;#34;, 1, MSG_OOB);
     recv(sk[1], buf, 0, MSG_OOB);
     send(sk[0], &amp;#34;b&amp;#34;, 1, MSG_OOB);
     recv(sk[1], buf, 1, MSG_PEEK);&lt;/p&gt;
&lt;p&gt;Then, @copied is 0 in unix_stream_read_generic() (zero-length buffer,
or non-OOB skb is not yet consumed), and unix_stream_data_wait() is
called.&lt;/p&gt;
&lt;p&gt;However, it returns immediately because @last is not updated in
unix_stream_read_generic(), and the thread busy-waits for a new skb.&lt;/p&gt;
&lt;p&gt;Let&amp;#39;s update @last in manage_oob().&lt;/p&gt;
&lt;p&gt;For MSG_PEEK, @last is updated with the skipped OOB, and for the
non-peek case, @last matches the returned value (when !copied)
because OOB is unlinked.&lt;/p&gt;
&lt;p&gt;Note that manage_oob() is inlined and no stack canary is added.&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;af_unix: Update last skb marker in manage_oob().&lt;/p&gt;
&lt;p&gt;Fahad Alharbi reported that blocking recv(MSG_PEEK) could hog CPU
due to OOB skb.&lt;/p&gt;
&lt;p&gt;In the following cases, manage_oob() skips OOB skb(s) and returns
NULL for the last recv(MSG_PEEK):&lt;/p&gt;
&lt;p&gt;socketpair(AF_UNIX, SOCK_STREAM, 0, sk);&lt;/p&gt;
&lt;p&gt;1) skb -&amp;gt; OOB skb -&amp;gt; NULL
     send(sk[0], &amp;#34;ab&amp;#34;, 2, MSG_OOB);
     recv(sk[1], buf, 0, MSG_PEEK);&lt;/p&gt;
&lt;p&gt;2) skb -&amp;gt; consumed OOB skb -&amp;gt; NULL
     send(sk[0], &amp;#34;ab&amp;#34;, 2, MSG_OOB);
     recv(sk[1], buf, 1, MSG_OOB);
     recv(sk[1], buf, 0, MSG_PEEK);&lt;/p&gt;
&lt;p&gt;3) consumed OOB skb -&amp;gt; OOB skb -&amp;gt; NULL
     send(sk[0], &amp;#34;a&amp;#34;, 1, MSG_OOB);
     recv(sk[1], buf, 0, MSG_OOB);
     send(sk[0], &amp;#34;b&amp;#34;, 1, MSG_OOB);
     recv(sk[1], buf, 1, MSG_PEEK);&lt;/p&gt;
&lt;p&gt;Then, @copied is 0 in unix_stream_read_generic() (zero-length buffer,
or non-OOB skb is not yet consumed), and unix_stream_data_wait() is
called.&lt;/p&gt;
&lt;p&gt;However, it returns immediately because @last is not updated in
unix_stream_read_generic(), and the thread busy-waits for a new skb.&lt;/p&gt;
&lt;p&gt;Let&amp;#39;s update @last in manage_oob().&lt;/p&gt;
&lt;p&gt;For MSG_PEEK, @last is updated with the skipped OOB, and for the
non-peek case, @last matches the returned value (when !copied)
because OOB is unlinked.&lt;/p&gt;
&lt;p&gt;Note that manage_oob() is inlined and no stack canary is added.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-cq66-2f6w-rhg5</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-97985</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-97985</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: af_unix: Update last skb marker in manage_oob(). Fahad Alharbi reported that blocking recv(MSG_PEEK) could hog CPU due to OOB skb. In the following cases, manage_oob() skips OOB skb(s) and returns NULL for the last recv(MSG_PEEK):   socketpair(AF_UNIX, SOCK_STREAM, 0, sk);   1) skb -&amp;gt; OOB skb -&amp;gt; NULL      send(sk[0], &amp;#34;ab&amp;#34;, 2, MSG_OOB);      recv(sk[1], buf, 0, MSG_PEEK);   2) skb -&amp;gt; consumed OOB skb -&amp;gt; NULL      send(sk[0], &amp;#34;ab&amp;#34;, 2, MSG_OOB);      recv(sk[1], buf, 1, MSG_OOB);      recv(sk[1], buf, 0, MSG_PEEK);   3) consumed OOB skb -&amp;gt; OOB skb -&amp;gt; NULL      send(sk[0], &amp;#34;a&amp;#34;, 1, MSG_OOB);      recv(sk[1], buf, 0, MSG_OOB);      send(sk[0], &amp;#34;b&amp;#34;, 1, MSG_OOB);      recv(sk[1], buf, 1, MSG_PEEK); Then, @copied is 0 in unix_stream_read_generic() (zero-length buffer, or non-OOB skb is not yet consumed), and unix_stream_data_wait() is called. However, it returns immediately because @last is not updated in unix_stream_read_generic(), and the thread busy-waits for a new skb. Let&amp;#39;s update @last in manage_oob(). For MSG_PEEK, @last is updated with the skipped OOB, and for the non-peek case, @last matches the returned value (when !copied) because OOB is unlinked. Note that manage_oob() is inlined and no stack canary is added.&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: af_unix: Update last skb marker in manage_oob(). Fahad Alharbi reported that blocking recv(MSG_PEEK) could hog CPU due to OOB skb. In the following cases, manage_oob() skips OOB skb(s) and returns NULL for the last recv(MSG_PEEK):   socketpair(AF_UNIX, SOCK_STREAM, 0, sk);   1) skb -&amp;gt; OOB skb -&amp;gt; NULL      send(sk[0], &amp;#34;ab&amp;#34;, 2, MSG_OOB);      recv(sk[1], buf, 0, MSG_PEEK);   2) skb -&amp;gt; consumed OOB skb -&amp;gt; NULL      send(sk[0], &amp;#34;ab&amp;#34;, 2, MSG_OOB);      recv(sk[1], buf, 1, MSG_OOB);      recv(sk[1], buf, 0, MSG_PEEK);   3) consumed OOB skb -&amp;gt; OOB skb -&amp;gt; NULL      send(sk[0], &amp;#34;a&amp;#34;, 1, MSG_OOB);      recv(sk[1], buf, 0, MSG_OOB);      send(sk[0], &amp;#34;b&amp;#34;, 1, MSG_OOB);      recv(sk[1], buf, 1, MSG_PEEK); Then, @copied is 0 in unix_stream_read_generic() (zero-length buffer, or non-OOB skb is not yet consumed), and unix_stream_data_wait() is called. However, it returns immediately because @last is not updated in unix_stream_read_generic(), and the thread busy-waits for a new skb. Let&amp;#39;s update @last in manage_oob(). For MSG_PEEK, @last is updated with the skipped OOB, and for the non-peek case, @last matches the returned value (when !copied) because OOB is unlinked. Note that manage_oob() is inlined and no stack canary is added.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-97985</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-3579 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579</guid>
    </item>
  </channel>
</rss>
