<?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://cve.radiocsirt.org</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 08:21:04 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-23356</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-23356</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://cve.radiocsirt.org/vuln/bell-cve-2026-23356</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0376 — De multiples vulnérabilités ont été découvertes dans les produits Microsoft. Elles permettent à un attaquant de provoqu…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0376</link>
      <description>certfr-2026-avi-0376</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0376</guid>
    </item>
    <item>
      <title>EUVD-2026-315497</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-315497</link>
      <description>EUVD-2026-315497</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-315497</guid>
    </item>
    <item>
      <title>fkie_cve-2026-23356</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-23356</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drbd: fix &amp;#34;LOGIC BUG&amp;#34; in drbd_al_begin_io_nonblock()&lt;/p&gt;
&lt;p&gt;Even though we check that we &amp;#34;should&amp;#34; be able to do lc_get_cumulative()
while holding the device-&amp;gt;al_lock spinlock, it may still fail,
if some other code path decided to do lc_try_lock() with bad timing.&lt;/p&gt;
&lt;p&gt;If that happened, we logged &amp;#34;LOGIC BUG for enr=...&amp;#34;,
but still did not return an error.&lt;/p&gt;
&lt;p&gt;The rest of the code now assumed that this request has references
for the relevant activity log extents.&lt;/p&gt;
&lt;p&gt;The implcations are that during an active resync, mutual exclusivity of
resync versus application IO is not guaranteed. And a potential crash
at this point may not realizs that these extents could have been target
of in-flight IO and would need to be resynced just in case.&lt;/p&gt;
&lt;p&gt;Also, once the request completes, it will give up activity log references it
does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put().&lt;/p&gt;
&lt;p&gt;Fix:&lt;/p&gt;
&lt;p&gt;Do not crash the kernel for a condition that is harmless during normal
operation: also catch &amp;#34;e-&amp;gt;refcnt == 0&amp;#34;, not only &amp;#34;e == NULL&amp;#34;
when being noisy about &amp;#34;al_complete_io() called on inactive extent %u\n&amp;#34;.&lt;/p&gt;
&lt;p&gt;And do not try to be smart and &amp;#34;guess&amp;#34; whether something will work, then
be surprised when it does not.
Deal with the fact that it may or may not work.  If it does not, remember a
possible &amp;#34;partially in activity log&amp;#34; state (only possible for requests that
cross extent boundaries), and return an error code from
drbd_al_begin_io_nonbloc…&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;drbd: fix &amp;#34;LOGIC BUG&amp;#34; in drbd_al_begin_io_nonblock()&lt;/p&gt;
&lt;p&gt;Even though we check that we &amp;#34;should&amp;#34; be able to do lc_get_cumulative()
while holding the device-&amp;gt;al_lock spinlock, it may still fail,
if some other code path decided to do lc_try_lock() with bad timing.&lt;/p&gt;
&lt;p&gt;If that happened, we logged &amp;#34;LOGIC BUG for enr=...&amp;#34;,
but still did not return an error.&lt;/p&gt;
&lt;p&gt;The rest of the code now assumed that this request has references
for the relevant activity log extents.&lt;/p&gt;
&lt;p&gt;The implcations are that during an active resync, mutual exclusivity of
resync versus application IO is not guaranteed. And a potential crash
at this point may not realizs that these extents could have been target
of in-flight IO and would need to be resynced just in case.&lt;/p&gt;
&lt;p&gt;Also, once the request completes, it will give up activity log references it
does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put().&lt;/p&gt;
&lt;p&gt;Fix:&lt;/p&gt;
&lt;p&gt;Do not crash the kernel for a condition that is harmless during normal
operation: also catch &amp;#34;e-&amp;gt;refcnt == 0&amp;#34;, not only &amp;#34;e == NULL&amp;#34;
when being noisy about &amp;#34;al_complete_io() called on inactive extent %u\n&amp;#34;.&lt;/p&gt;
&lt;p&gt;And do not try to be smart and &amp;#34;guess&amp;#34; whether something will work, then
be surprised when it does not.
Deal with the fact that it may or may not work.  If it does not, remember a
possible &amp;#34;partially in activity log&amp;#34; state (only possible for requests that
cross extent boundaries), and return an error code from
drbd_al_begin_io_nonbloc…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-23356</guid>
    </item>
    <item>
      <title>GHSA-rp6p-x9w7-2rqg</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-rp6p-x9w7-2rqg</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drbd: fix &amp;#34;LOGIC BUG&amp;#34; in drbd_al_begin_io_nonblock()&lt;/p&gt;
&lt;p&gt;Even though we check that we &amp;#34;should&amp;#34; be able to do lc_get_cumulative()
while holding the device-&amp;gt;al_lock spinlock, it may still fail,
if some other code path decided to do lc_try_lock() with bad timing.&lt;/p&gt;
&lt;p&gt;If that happened, we logged &amp;#34;LOGIC BUG for enr=...&amp;#34;,
but still did not return an error.&lt;/p&gt;
&lt;p&gt;The rest of the code now assumed that this request has references
for the relevant activity log extents.&lt;/p&gt;
&lt;p&gt;The implcations are that during an active resync, mutual exclusivity of
resync versus application IO is not guaranteed. And a potential crash
at this point may not realizs that these extents could have been target
of in-flight IO and would need to be resynced just in case.&lt;/p&gt;
&lt;p&gt;Also, once the request completes, it will give up activity log references it
does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put().&lt;/p&gt;
&lt;p&gt;Fix:&lt;/p&gt;
&lt;p&gt;Do not crash the kernel for a condition that is harmless during normal
operation: also catch &amp;#34;e-&amp;gt;refcnt == 0&amp;#34;, not only &amp;#34;e == NULL&amp;#34;
when being noisy about &amp;#34;al_complete_io() called on inactive extent %u\n&amp;#34;.&lt;/p&gt;
&lt;p&gt;And do not try to be smart and &amp;#34;guess&amp;#34; whether something will work, then
be surprised when it does not.
Deal with the fact that it may or may not work.  If it does not, remember a
possible &amp;#34;partially in activity log&amp;#34; state (only possible for requests that
cross extent boundaries), and return an error code from
drbd_al_begin_io_nonbloc…&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;drbd: fix &amp;#34;LOGIC BUG&amp;#34; in drbd_al_begin_io_nonblock()&lt;/p&gt;
&lt;p&gt;Even though we check that we &amp;#34;should&amp;#34; be able to do lc_get_cumulative()
while holding the device-&amp;gt;al_lock spinlock, it may still fail,
if some other code path decided to do lc_try_lock() with bad timing.&lt;/p&gt;
&lt;p&gt;If that happened, we logged &amp;#34;LOGIC BUG for enr=...&amp;#34;,
but still did not return an error.&lt;/p&gt;
&lt;p&gt;The rest of the code now assumed that this request has references
for the relevant activity log extents.&lt;/p&gt;
&lt;p&gt;The implcations are that during an active resync, mutual exclusivity of
resync versus application IO is not guaranteed. And a potential crash
at this point may not realizs that these extents could have been target
of in-flight IO and would need to be resynced just in case.&lt;/p&gt;
&lt;p&gt;Also, once the request completes, it will give up activity log references it
does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put().&lt;/p&gt;
&lt;p&gt;Fix:&lt;/p&gt;
&lt;p&gt;Do not crash the kernel for a condition that is harmless during normal
operation: also catch &amp;#34;e-&amp;gt;refcnt == 0&amp;#34;, not only &amp;#34;e == NULL&amp;#34;
when being noisy about &amp;#34;al_complete_io() called on inactive extent %u\n&amp;#34;.&lt;/p&gt;
&lt;p&gt;And do not try to be smart and &amp;#34;guess&amp;#34; whether something will work, then
be surprised when it does not.
Deal with the fact that it may or may not work.  If it does not, remember a
possible &amp;#34;partially in activity log&amp;#34; state (only possible for requests that
cross extent boundaries), and return an error code from
drbd_al_begin_io_nonbloc…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-rp6p-x9w7-2rqg</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-23356 — drbd: fix "LOGIC BUG" in drbd_al_begin_io_nonblock()</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-23356</link>
      <description>msrc_CVE-2026-23356</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-23356</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-23356</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23356</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 232 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: drbd: fix &amp;#34;LOGIC BUG&amp;#34; in drbd_al_begin_io_nonblock() Even though we check that we &amp;#34;should&amp;#34; be able to do lc_get_cumulative() while holding the device-&amp;gt;al_lock spinlock, it may still fail, if some other code path decided to do lc_try_lock() with bad timing. If that happened, we logged &amp;#34;LOGIC BUG for enr=...&amp;#34;, but still did not return an error. The rest of the code now assumed that this request has references for the relevant activity log extents. The implcations are that during an active resync, mutual exclusivity of resync versus application IO is not guaranteed. And a potential crash at this point may not realizs that these extents could have been target of in-flight IO and would need to be resynced just in case. Also, once the request completes, it will give up activity log references it does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put(). Fix: Do not crash the kernel for a condition that is harmless during normal operation: also catch &amp;#34;e-&amp;gt;refcnt == 0&amp;#34;, not only &amp;#34;e == NULL&amp;#34; when being noisy about &amp;#34;al_complete_io() called on inactive extent %u\n&amp;#34;. And do not try to be smart and &amp;#34;guess&amp;#34; whether something will work, then be surprised when it does not. Deal with the fact that it may or may not work.  If it does not, remember a possible &amp;#34;partially in activity log&amp;#34; state (only possible for requests that cross extent boundaries), and return an error code from drbd_al_begin_io_nonblock(). A la…&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 232 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: drbd: fix &amp;#34;LOGIC BUG&amp;#34; in drbd_al_begin_io_nonblock() Even though we check that we &amp;#34;should&amp;#34; be able to do lc_get_cumulative() while holding the device-&amp;gt;al_lock spinlock, it may still fail, if some other code path decided to do lc_try_lock() with bad timing. If that happened, we logged &amp;#34;LOGIC BUG for enr=...&amp;#34;, but still did not return an error. The rest of the code now assumed that this request has references for the relevant activity log extents. The implcations are that during an active resync, mutual exclusivity of resync versus application IO is not guaranteed. And a potential crash at this point may not realizs that these extents could have been target of in-flight IO and would need to be resynced just in case. Also, once the request completes, it will give up activity log references it does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put(). Fix: Do not crash the kernel for a condition that is harmless during normal operation: also catch &amp;#34;e-&amp;gt;refcnt == 0&amp;#34;, not only &amp;#34;e == NULL&amp;#34; when being noisy about &amp;#34;al_complete_io() called on inactive extent %u\n&amp;#34;. And do not try to be smart and &amp;#34;guess&amp;#34; whether something will work, then be surprised when it does not. Deal with the fact that it may or may not work.  If it does not, remember a possible &amp;#34;partially in activity log&amp;#34; state (only possible for requests that cross extent boundaries), and return an error code from drbd_al_begin_io_nonblock(). A la…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23356</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-0861 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0861</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service zu verursachen, Sicherheitsmaßnahmen zu umgehen, Informationen offenzulegen, weitere nicht spezifizierte Auswirkungen zu verursachen und potentiell Code auszuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service zu verursachen, Sicherheitsmaßnahmen zu umgehen, Informationen offenzulegen, weitere nicht spezifizierte Auswirkungen zu verursachen und potentiell Code auszuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0861</guid>
    </item>
  </channel>
</rss>
