<?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>Sat, 03 Oct 2026 06:43:14 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-23177 — mm, shmem: prevent infinite loop on truncate race</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-23177</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mm, shmem: prevent infinite loop on truncate race&lt;/p&gt;
&lt;p&gt;When truncating a large swap entry, shmem_free_swap() returns 0 when the
entry&amp;#39;s index doesn&amp;#39;t match the given index due to lookup alignment.  The
failure fallback path checks if the entry crosses the end border and
aborts when it happens, so truncate won&amp;#39;t erase an unexpected entry or
range.  But one scenario was ignored.&lt;/p&gt;
&lt;p&gt;When `index` points to the middle of a large swap entry, and the large
swap entry doesn&amp;#39;t go across the end border, find_get_entries() will
return that large swap entry as the first item in the batch with
`indices[0]` equal to `index`.  The entry&amp;#39;s base index will be smaller
than `indices[0]`, so shmem_free_swap() will fail and return 0 due to the
&amp;#34;base &amp;lt; index&amp;#34; check.  The code will then call shmem_confirm_swap(), get
the order, check if it crosses the END boundary (which it doesn&amp;#39;t), and
retry with the same index.&lt;/p&gt;
&lt;p&gt;The next iteration will find the same entry again at the same index with
same indices, leading to an infinite loop.&lt;/p&gt;
&lt;p&gt;Fix this by retrying with a round-down index, and abort if the index is
smaller than the truncate range.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mm, shmem: prevent infinite loop on truncate race&lt;/p&gt;
&lt;p&gt;When truncating a large swap entry, shmem_free_swap() returns 0 when the
entry&amp;#39;s index doesn&amp;#39;t match the given index due to lookup alignment.  The
failure fallback path checks if the entry crosses the end border and
aborts when it happens, so truncate won&amp;#39;t erase an unexpected entry or
range.  But one scenario was ignored.&lt;/p&gt;
&lt;p&gt;When `index` points to the middle of a large swap entry, and the large
swap entry doesn&amp;#39;t go across the end border, find_get_entries() will
return that large swap entry as the first item in the batch with
`indices[0]` equal to `index`.  The entry&amp;#39;s base index will be smaller
than `indices[0]`, so shmem_free_swap() will fail and return 0 due to the
&amp;#34;base &amp;lt; index&amp;#34; check.  The code will then call shmem_confirm_swap(), get
the order, check if it crosses the END boundary (which it doesn&amp;#39;t), and
retry with the same index.&lt;/p&gt;
&lt;p&gt;The next iteration will find the same entry again at the same index with
same indices, leading to an infinite loop.&lt;/p&gt;
&lt;p&gt;Fix this by retrying with a round-down index, and abort if the index is
smaller than the truncate range.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-23177</guid>
    </item>
  </channel>
</rss>
