<?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>Sat, 03 Oct 2026 02:27:42 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-43065</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-43065</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-43065</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0782 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0782</link>
      <description>certfr-2026-avi-0782</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0782</guid>
    </item>
    <item>
      <title>EUVD-2026-315732</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-315732</link>
      <description>EUVD-2026-315732</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-315732</guid>
    </item>
    <item>
      <title>fkie_cve-2026-43065</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-43065</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ext4: always drain queued discard work in ext4_mb_release()&lt;/p&gt;
&lt;p&gt;While reviewing recent ext4 patch[1], Sashiko raised the following
concern[2]:&lt;/p&gt;
&lt;p&gt;&amp;gt; If the filesystem is initially mounted with the discard option,
&amp;gt; deleting files will populate sbi-&amp;gt;s_discard_list and queue
&amp;gt; s_discard_work. If it is then remounted with nodiscard, the
&amp;gt; EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is
&amp;gt; neither cancelled nor flushed.&lt;/p&gt;
&lt;p&gt;[1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/
[2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev&lt;/p&gt;
&lt;p&gt;The concern was valid, but it had nothing to do with the patch[1].
One of the problems with Sashiko in its current (early) form is that
it will detect pre-existing issues and report it as a problem with the
patch that it is reviewing.&lt;/p&gt;
&lt;p&gt;In practice, it would be hard to hit deliberately (unless you are a
malicious syzkaller fuzzer), since it would involve mounting the file
system with -o discard, and then deleting a large number of files,
remounting the file system with -o nodiscard, and then immediately
unmounting the file system before the queued discard work has a change
to drain on its own.&lt;/p&gt;
&lt;p&gt;Fix it because it&amp;#39;s a real bug, and to avoid Sashiko from raising this
concern when analyzing future patches to mballoc.c.&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;ext4: always drain queued discard work in ext4_mb_release()&lt;/p&gt;
&lt;p&gt;While reviewing recent ext4 patch[1], Sashiko raised the following
concern[2]:&lt;/p&gt;
&lt;p&gt;&amp;gt; If the filesystem is initially mounted with the discard option,
&amp;gt; deleting files will populate sbi-&amp;gt;s_discard_list and queue
&amp;gt; s_discard_work. If it is then remounted with nodiscard, the
&amp;gt; EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is
&amp;gt; neither cancelled nor flushed.&lt;/p&gt;
&lt;p&gt;[1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/
[2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev&lt;/p&gt;
&lt;p&gt;The concern was valid, but it had nothing to do with the patch[1].
One of the problems with Sashiko in its current (early) form is that
it will detect pre-existing issues and report it as a problem with the
patch that it is reviewing.&lt;/p&gt;
&lt;p&gt;In practice, it would be hard to hit deliberately (unless you are a
malicious syzkaller fuzzer), since it would involve mounting the file
system with -o discard, and then deleting a large number of files,
remounting the file system with -o nodiscard, and then immediately
unmounting the file system before the queued discard work has a change
to drain on its own.&lt;/p&gt;
&lt;p&gt;Fix it because it&amp;#39;s a real bug, and to avoid Sashiko from raising this
concern when analyzing future patches to mballoc.c.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-43065</guid>
    </item>
    <item>
      <title>GHSA-86wv-8x6p-4rhg</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-86wv-8x6p-4rhg</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ext4: always drain queued discard work in ext4_mb_release()&lt;/p&gt;
&lt;p&gt;While reviewing recent ext4 patch[1], Sashiko raised the following
concern[2]:&lt;/p&gt;
&lt;p&gt;&amp;gt; If the filesystem is initially mounted with the discard option,
&amp;gt; deleting files will populate sbi-&amp;gt;s_discard_list and queue
&amp;gt; s_discard_work. If it is then remounted with nodiscard, the
&amp;gt; EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is
&amp;gt; neither cancelled nor flushed.&lt;/p&gt;
&lt;p&gt;[1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/
[2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev&lt;/p&gt;
&lt;p&gt;The concern was valid, but it had nothing to do with the patch[1].
One of the problems with Sashiko in its current (early) form is that
it will detect pre-existing issues and report it as a problem with the
patch that it is reviewing.&lt;/p&gt;
&lt;p&gt;In practice, it would be hard to hit deliberately (unless you are a
malicious syzkaller fuzzer), since it would involve mounting the file
system with -o discard, and then deleting a large number of files,
remounting the file system with -o nodiscard, and then immediately
unmounting the file system before the queued discard work has a change
to drain on its own.&lt;/p&gt;
&lt;p&gt;Fix it because it&amp;#39;s a real bug, and to avoid Sashiko from raising this
concern when analyzing future patches to mballoc.c.&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;ext4: always drain queued discard work in ext4_mb_release()&lt;/p&gt;
&lt;p&gt;While reviewing recent ext4 patch[1], Sashiko raised the following
concern[2]:&lt;/p&gt;
&lt;p&gt;&amp;gt; If the filesystem is initially mounted with the discard option,
&amp;gt; deleting files will populate sbi-&amp;gt;s_discard_list and queue
&amp;gt; s_discard_work. If it is then remounted with nodiscard, the
&amp;gt; EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is
&amp;gt; neither cancelled nor flushed.&lt;/p&gt;
&lt;p&gt;[1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/
[2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev&lt;/p&gt;
&lt;p&gt;The concern was valid, but it had nothing to do with the patch[1].
One of the problems with Sashiko in its current (early) form is that
it will detect pre-existing issues and report it as a problem with the
patch that it is reviewing.&lt;/p&gt;
&lt;p&gt;In practice, it would be hard to hit deliberately (unless you are a
malicious syzkaller fuzzer), since it would involve mounting the file
system with -o discard, and then deleting a large number of files,
remounting the file system with -o nodiscard, and then immediately
unmounting the file system before the queued discard work has a change
to drain on its own.&lt;/p&gt;
&lt;p&gt;Fix it because it&amp;#39;s a real bug, and to avoid Sashiko from raising this
concern when analyzing future patches to mballoc.c.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-86wv-8x6p-4rhg</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:20965-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:20965-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://cve.radiocsirt.org/vuln/opensuse-su-2026:20965-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:22099-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:22099-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://cve.radiocsirt.org/vuln/suse-su-2026:22099-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-43065</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43065</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:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 179 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ext4: always drain queued discard work in ext4_mb_release() While reviewing recent ext4 patch[1], Sashiko raised the following concern[2]: &amp;gt; If the filesystem is initially mounted with the discard option, &amp;gt; deleting files will populate sbi-&amp;gt;s_discard_list and queue &amp;gt; s_discard_work. If it is then remounted with nodiscard, the &amp;gt; EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is &amp;gt; neither cancelled nor flushed. [1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/ [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev The concern was valid, but it had nothing to do with the patch[1]. One of the problems with Sashiko in its current (early) form is that it will detect pre-existing issues and report it as a problem with the patch that it is reviewing. In practice, it would be hard to hit deliberately (unless you are a malicious syzkaller fuzzer), since it would involve mounting the file system with -o discard, and then deleting a large number of files, remounting the file system with -o nodiscard, and then immediately unmounting the file system before the queued discard work has a change to drain on its own. Fix it because it&amp;#39;s a real bug, and to avoid Sashiko from raising this concern when analyzing future patches to mballoc.c.&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:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 179 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ext4: always drain queued discard work in ext4_mb_release() While reviewing recent ext4 patch[1], Sashiko raised the following concern[2]: &amp;gt; If the filesystem is initially mounted with the discard option, &amp;gt; deleting files will populate sbi-&amp;gt;s_discard_list and queue &amp;gt; s_discard_work. If it is then remounted with nodiscard, the &amp;gt; EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is &amp;gt; neither cancelled nor flushed. [1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/ [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev The concern was valid, but it had nothing to do with the patch[1]. One of the problems with Sashiko in its current (early) form is that it will detect pre-existing issues and report it as a problem with the patch that it is reviewing. In practice, it would be hard to hit deliberately (unless you are a malicious syzkaller fuzzer), since it would involve mounting the file system with -o discard, and then deleting a large number of files, remounting the file system with -o nodiscard, and then immediately unmounting the file system before the queued discard work has a change to drain on its own. Fix it because it&amp;#39;s a real bug, and to avoid Sashiko from raising this concern when analyzing future patches to mballoc.c.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43065</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1385 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1385</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service zu verursachen, Informationen offenzulegen, Sicherheitsmaßnahmen zu umgehen oder potentiell beliebigen Programmcode auszufü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 zu verursachen, Informationen offenzulegen, Sicherheitsmaßnahmen zu umgehen oder potentiell beliebigen Programmcode auszuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1385</guid>
    </item>
  </channel>
</rss>
