<?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 11:27:07 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-72367</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-72367</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-72367</guid>
    </item>
    <item>
      <title>EUVD-2026-354050</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-354050</link>
      <description>EUVD-2026-354050</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-354050</guid>
    </item>
    <item>
      <title>fkie_cve-2026-72367</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-72367</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;iomap: guard io_size EOF trim against concurrent truncate underflow&lt;/p&gt;
&lt;p&gt;iomap: fix zero padding data issue in concurrent append writes
changed ioend accounting so that io_size tracks only valid data
within EOF.  This trims io_size when a writeback range extends
past end_pos:&lt;/p&gt;
&lt;p&gt;ioend-&amp;gt;io_size += map_len;
    if (ioend-&amp;gt;io_offset + ioend-&amp;gt;io_size &amp;gt; end_pos)
        ioend-&amp;gt;io_size = end_pos - ioend-&amp;gt;io_offset;&lt;/p&gt;
&lt;p&gt;However, if end_pos ends up below ioend-&amp;gt;io_offset, the subtraction
becomes negative and is stored in size_t io_size, causing an unsigned
wrap to a huge value.  This can happen when writeback continues past
byte-level EOF up to a block-aligned range, or when a concurrent
truncate shrinks the file after end_pos was sampled in
iomap_writeback_handle_eof().&lt;/p&gt;
&lt;p&gt;A wrapped io_size can mislead append detection and corrupt
completion-time size handling, since filesystem end_io paths consume
io_size for decisions such as on-disk EOF updates and unwritten/COW
completion ranges.&lt;/p&gt;
&lt;p&gt;Fix this by clamping io_size to zero when EOF has moved to or before
the ioend start offset.  This preserves the original intent of trimming
io_size to valid in-EOF data while avoiding the underflow.&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;iomap: guard io_size EOF trim against concurrent truncate underflow&lt;/p&gt;
&lt;p&gt;iomap: fix zero padding data issue in concurrent append writes
changed ioend accounting so that io_size tracks only valid data
within EOF.  This trims io_size when a writeback range extends
past end_pos:&lt;/p&gt;
&lt;p&gt;ioend-&amp;gt;io_size += map_len;
    if (ioend-&amp;gt;io_offset + ioend-&amp;gt;io_size &amp;gt; end_pos)
        ioend-&amp;gt;io_size = end_pos - ioend-&amp;gt;io_offset;&lt;/p&gt;
&lt;p&gt;However, if end_pos ends up below ioend-&amp;gt;io_offset, the subtraction
becomes negative and is stored in size_t io_size, causing an unsigned
wrap to a huge value.  This can happen when writeback continues past
byte-level EOF up to a block-aligned range, or when a concurrent
truncate shrinks the file after end_pos was sampled in
iomap_writeback_handle_eof().&lt;/p&gt;
&lt;p&gt;A wrapped io_size can mislead append detection and corrupt
completion-time size handling, since filesystem end_io paths consume
io_size for decisions such as on-disk EOF updates and unwritten/COW
completion ranges.&lt;/p&gt;
&lt;p&gt;Fix this by clamping io_size to zero when EOF has moved to or before
the ioend start offset.  This preserves the original intent of trimming
io_size to valid in-EOF data while avoiding the underflow.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-72367</guid>
    </item>
    <item>
      <title>GHSA-r9wm-p769-97j8</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-r9wm-p769-97j8</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;iomap: guard io_size EOF trim against concurrent truncate underflow&lt;/p&gt;
&lt;p&gt;iomap: fix zero padding data issue in concurrent append writes
changed ioend accounting so that io_size tracks only valid data
within EOF.  This trims io_size when a writeback range extends
past end_pos:&lt;/p&gt;
&lt;p&gt;ioend-&amp;gt;io_size += map_len;
    if (ioend-&amp;gt;io_offset + ioend-&amp;gt;io_size &amp;gt; end_pos)
        ioend-&amp;gt;io_size = end_pos - ioend-&amp;gt;io_offset;&lt;/p&gt;
&lt;p&gt;However, if end_pos ends up below ioend-&amp;gt;io_offset, the subtraction
becomes negative and is stored in size_t io_size, causing an unsigned
wrap to a huge value.  This can happen when writeback continues past
byte-level EOF up to a block-aligned range, or when a concurrent
truncate shrinks the file after end_pos was sampled in
iomap_writeback_handle_eof().&lt;/p&gt;
&lt;p&gt;A wrapped io_size can mislead append detection and corrupt
completion-time size handling, since filesystem end_io paths consume
io_size for decisions such as on-disk EOF updates and unwritten/COW
completion ranges.&lt;/p&gt;
&lt;p&gt;Fix this by clamping io_size to zero when EOF has moved to or before
the ioend start offset.  This preserves the original intent of trimming
io_size to valid in-EOF data while avoiding the underflow.&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;iomap: guard io_size EOF trim against concurrent truncate underflow&lt;/p&gt;
&lt;p&gt;iomap: fix zero padding data issue in concurrent append writes
changed ioend accounting so that io_size tracks only valid data
within EOF.  This trims io_size when a writeback range extends
past end_pos:&lt;/p&gt;
&lt;p&gt;ioend-&amp;gt;io_size += map_len;
    if (ioend-&amp;gt;io_offset + ioend-&amp;gt;io_size &amp;gt; end_pos)
        ioend-&amp;gt;io_size = end_pos - ioend-&amp;gt;io_offset;&lt;/p&gt;
&lt;p&gt;However, if end_pos ends up below ioend-&amp;gt;io_offset, the subtraction
becomes negative and is stored in size_t io_size, causing an unsigned
wrap to a huge value.  This can happen when writeback continues past
byte-level EOF up to a block-aligned range, or when a concurrent
truncate shrinks the file after end_pos was sampled in
iomap_writeback_handle_eof().&lt;/p&gt;
&lt;p&gt;A wrapped io_size can mislead append detection and corrupt
completion-time size handling, since filesystem end_io paths consume
io_size for decisions such as on-disk EOF updates and unwritten/COW
completion ranges.&lt;/p&gt;
&lt;p&gt;Fix this by clamping io_size to zero when EOF has moved to or before
the ioend start offset.  This preserves the original intent of trimming
io_size to valid in-EOF data while avoiding the underflow.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-r9wm-p769-97j8</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-72367</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-72367</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 120 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: iomap: guard io_size EOF trim against concurrent truncate underflow iomap: fix zero padding data issue in concurrent append writes changed ioend accounting so that io_size tracks only valid data within EOF.  This trims io_size when a writeback range extends past end_pos:     ioend-&amp;gt;io_size += map_len;     if (ioend-&amp;gt;io_offset + ioend-&amp;gt;io_size &amp;gt; end_pos)         ioend-&amp;gt;io_size = end_pos - ioend-&amp;gt;io_offset; However, if end_pos ends up below ioend-&amp;gt;io_offset, the subtraction becomes negative and is stored in size_t io_size, causing an unsigned wrap to a huge value.  This can happen when writeback continues past byte-level EOF up to a block-aligned range, or when a concurrent truncate shrinks the file after end_pos was sampled in iomap_writeback_handle_eof(). A wrapped io_size can mislead append detection and corrupt completion-time size handling, since filesystem end_io paths consume io_size for decisions such as on-disk EOF updates and unwritten/COW completion ranges. Fix this by clamping io_size to zero when EOF has moved to or before the ioend start offset.  This preserves the original intent of trimming io_size to valid in-EOF data while avoiding the underflow.&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 120 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: iomap: guard io_size EOF trim against concurrent truncate underflow iomap: fix zero padding data issue in concurrent append writes changed ioend accounting so that io_size tracks only valid data within EOF.  This trims io_size when a writeback range extends past end_pos:     ioend-&amp;gt;io_size += map_len;     if (ioend-&amp;gt;io_offset + ioend-&amp;gt;io_size &amp;gt; end_pos)         ioend-&amp;gt;io_size = end_pos - ioend-&amp;gt;io_offset; However, if end_pos ends up below ioend-&amp;gt;io_offset, the subtraction becomes negative and is stored in size_t io_size, causing an unsigned wrap to a huge value.  This can happen when writeback continues past byte-level EOF up to a block-aligned range, or when a concurrent truncate shrinks the file after end_pos was sampled in iomap_writeback_handle_eof(). A wrapped io_size can mislead append detection and corrupt completion-time size handling, since filesystem end_io paths consume io_size for decisions such as on-disk EOF updates and unwritten/COW completion ranges. Fix this by clamping io_size to zero when EOF has moved to or before the ioend start offset.  This preserves the original intent of trimming io_size to valid in-EOF data while avoiding the underflow.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-72367</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2852 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852</guid>
    </item>
  </channel>
</rss>
