<?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>Fri, 02 Oct 2026 19:41:03 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-45858</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-45858</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-45858</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0926 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0926</link>
      <description>certfr-2026-avi-0926</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0926</guid>
    </item>
    <item>
      <title>EUVD-2026-323192</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-323192</link>
      <description>EUVD-2026-323192</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-323192</guid>
    </item>
    <item>
      <title>fkie_cve-2026-45858</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-45858</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ext4: don&amp;#39;t zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1&lt;/p&gt;
&lt;p&gt;When allocating initialized blocks from a large unwritten extent, or
when splitting an unwritten extent during end I/O and converting it to
initialized, there is currently a potential issue of stale data if the
extent needs to be split in the middle.&lt;/p&gt;
&lt;p&gt;0  A      B  N
       [UUUUUUUUUUUU]    U: unwritten extent
       [--DDDDDDDD--]    D: valid data
          |&amp;lt;-  -&amp;gt;| ----&amp;gt; this range needs to be initialized&lt;/p&gt;
&lt;p&gt;ext4_split_extent() first try to split this extent at B with
EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but
ext4_split_extent_at() failed to split this extent due to temporary lack
of space. It zeroout B to N and mark the entire extent from 0 to N
as written.&lt;/p&gt;
&lt;p&gt;0  A      B  N
       [WWWWWWWWWWWW]    W: written extent
       [SSDDDDDDDDZZ]    Z: zeroed, S: stale data&lt;/p&gt;
&lt;p&gt;ext4_split_extent() then try to split this extent at A with
EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left
a stale written extent from 0 to A.&lt;/p&gt;
&lt;p&gt;0  A      B   N
       [WW|WWWWWWWWWW]
       [SS|DDDDDDDDZZ]&lt;/p&gt;
&lt;p&gt;Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at()
when splitting at B, don&amp;#39;t convert the entire extent to written and left
it as unwritten after zeroing out B to N. The remaining work is just
like the standard two-part split. ext4_split_extent() will pass the
EXT4_EXT_DATA_VALID2 fla…&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: don&amp;#39;t zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1&lt;/p&gt;
&lt;p&gt;When allocating initialized blocks from a large unwritten extent, or
when splitting an unwritten extent during end I/O and converting it to
initialized, there is currently a potential issue of stale data if the
extent needs to be split in the middle.&lt;/p&gt;
&lt;p&gt;0  A      B  N
       [UUUUUUUUUUUU]    U: unwritten extent
       [--DDDDDDDD--]    D: valid data
          |&amp;lt;-  -&amp;gt;| ----&amp;gt; this range needs to be initialized&lt;/p&gt;
&lt;p&gt;ext4_split_extent() first try to split this extent at B with
EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but
ext4_split_extent_at() failed to split this extent due to temporary lack
of space. It zeroout B to N and mark the entire extent from 0 to N
as written.&lt;/p&gt;
&lt;p&gt;0  A      B  N
       [WWWWWWWWWWWW]    W: written extent
       [SSDDDDDDDDZZ]    Z: zeroed, S: stale data&lt;/p&gt;
&lt;p&gt;ext4_split_extent() then try to split this extent at A with
EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left
a stale written extent from 0 to A.&lt;/p&gt;
&lt;p&gt;0  A      B   N
       [WW|WWWWWWWWWW]
       [SS|DDDDDDDDZZ]&lt;/p&gt;
&lt;p&gt;Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at()
when splitting at B, don&amp;#39;t convert the entire extent to written and left
it as unwritten after zeroing out B to N. The remaining work is just
like the standard two-part split. ext4_split_extent() will pass the
EXT4_EXT_DATA_VALID2 fla…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-45858</guid>
    </item>
    <item>
      <title>GHSA-pqwg-4rrm-3fg7</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-pqwg-4rrm-3fg7</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ext4: don&amp;#39;t zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1&lt;/p&gt;
&lt;p&gt;When allocating initialized blocks from a large unwritten extent, or
when splitting an unwritten extent during end I/O and converting it to
initialized, there is currently a potential issue of stale data if the
extent needs to be split in the middle.&lt;/p&gt;
&lt;p&gt;0  A      B  N
       [UUUUUUUUUUUU]    U: unwritten extent
       [--DDDDDDDD--]    D: valid data
          |&amp;lt;-  -&amp;gt;| ----&amp;gt; this range needs to be initialized&lt;/p&gt;
&lt;p&gt;ext4_split_extent() first try to split this extent at B with
EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but
ext4_split_extent_at() failed to split this extent due to temporary lack
of space. It zeroout B to N and mark the entire extent from 0 to N
as written.&lt;/p&gt;
&lt;p&gt;0  A      B  N
       [WWWWWWWWWWWW]    W: written extent
       [SSDDDDDDDDZZ]    Z: zeroed, S: stale data&lt;/p&gt;
&lt;p&gt;ext4_split_extent() then try to split this extent at A with
EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left
a stale written extent from 0 to A.&lt;/p&gt;
&lt;p&gt;0  A      B   N
       [WW|WWWWWWWWWW]
       [SS|DDDDDDDDZZ]&lt;/p&gt;
&lt;p&gt;Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at()
when splitting at B, don&amp;#39;t convert the entire extent to written and left
it as unwritten after zeroing out B to N. The remaining work is just
like the standard two-part split. ext4_split_extent() will pass the
EXT4_EXT_DATA_VALID2 fla…&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: don&amp;#39;t zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1&lt;/p&gt;
&lt;p&gt;When allocating initialized blocks from a large unwritten extent, or
when splitting an unwritten extent during end I/O and converting it to
initialized, there is currently a potential issue of stale data if the
extent needs to be split in the middle.&lt;/p&gt;
&lt;p&gt;0  A      B  N
       [UUUUUUUUUUUU]    U: unwritten extent
       [--DDDDDDDD--]    D: valid data
          |&amp;lt;-  -&amp;gt;| ----&amp;gt; this range needs to be initialized&lt;/p&gt;
&lt;p&gt;ext4_split_extent() first try to split this extent at B with
EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but
ext4_split_extent_at() failed to split this extent due to temporary lack
of space. It zeroout B to N and mark the entire extent from 0 to N
as written.&lt;/p&gt;
&lt;p&gt;0  A      B  N
       [WWWWWWWWWWWW]    W: written extent
       [SSDDDDDDDDZZ]    Z: zeroed, S: stale data&lt;/p&gt;
&lt;p&gt;ext4_split_extent() then try to split this extent at A with
EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left
a stale written extent from 0 to A.&lt;/p&gt;
&lt;p&gt;0  A      B   N
       [WW|WWWWWWWWWW]
       [SS|DDDDDDDDZZ]&lt;/p&gt;
&lt;p&gt;Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at()
when splitting at B, don&amp;#39;t convert the entire extent to written and left
it as unwritten after zeroing out B to N. The remaining work is just
like the standard two-part split. ext4_split_extent() will pass the
EXT4_EXT_DATA_VALID2 fla…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-pqwg-4rrm-3fg7</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-45858 — ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-45858</link>
      <description>msrc_CVE-2026-45858</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-45858</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:21388-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21388-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:21388-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:22742-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:22742-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:22742-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-45858</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45858</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: ext4: don&amp;#39;t zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1 When allocating initialized blocks from a large unwritten extent, or when splitting an unwritten extent during end I/O and converting it to initialized, there is currently a potential issue of stale data if the extent needs to be split in the middle.        0  A      B  N        [UUUUUUUUUUUU]    U: unwritten extent        [--DDDDDDDD--]    D: valid data           |&amp;lt;-  -&amp;gt;| ----&amp;gt; this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and mark the entire extent from 0 to N as written.        0  A      B  N        [WWWWWWWWWWWW]    W: written extent        [SSDDDDDDDDZZ]    Z: zeroed, S: stale data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left a stale written extent from 0 to A.        0  A      B   N        [WW|WWWWWWWWWW]        [SS|DDDDDDDDZZ] Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at() when splitting at B, don&amp;#39;t convert the entire extent to written and left it as unwritten after zeroing out B to N. The remaining work is just like the standard two-part split. ext4_split_extent() will pass the EXT4_EXT_DATA_VALID2 flag when i…&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: ext4: don&amp;#39;t zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1 When allocating initialized blocks from a large unwritten extent, or when splitting an unwritten extent during end I/O and converting it to initialized, there is currently a potential issue of stale data if the extent needs to be split in the middle.        0  A      B  N        [UUUUUUUUUUUU]    U: unwritten extent        [--DDDDDDDD--]    D: valid data           |&amp;lt;-  -&amp;gt;| ----&amp;gt; this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and mark the entire extent from 0 to N as written.        0  A      B  N        [WWWWWWWWWWWW]    W: written extent        [SSDDDDDDDDZZ]    Z: zeroed, S: stale data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left a stale written extent from 0 to A.        0  A      B   N        [WW|WWWWWWWWWW]        [SS|DDDDDDDDZZ] Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at() when splitting at B, don&amp;#39;t convert the entire extent to written and left it as unwritten after zeroing out B to N. The remaining work is just like the standard two-part split. ext4_split_extent() will pass the EXT4_EXT_DATA_VALID2 flag when i…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45858</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1700 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1700</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1700</guid>
    </item>
  </channel>
</rss>
