<?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>Mon, 28 Sep 2026 20:18:23 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-35797 — mm: cachestat: fix two shmem bugs</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2024-35797</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: cachestat: fix two shmem bugs&lt;/p&gt;
&lt;p&gt;When cachestat on shmem races with swapping and invalidation, there
are two possible bugs:&lt;/p&gt;
&lt;p&gt;1) A swapin error can have resulted in a poisoned swap entry in the
   shmem inode&amp;#39;s xarray. Calling get_shadow_from_swap_cache() on it
   will result in an out-of-bounds access to swapper_spaces[].&lt;/p&gt;
&lt;p&gt;Validate the entry with non_swap_entry() before going further.&lt;/p&gt;
&lt;p&gt;2) When we find a valid swap entry in the shmem&amp;#39;s inode, the shadow
   entry in the swapcache might not exist yet: swap IO is still in
   progress and we&amp;#39;re before __remove_mapping; swapin, invalidation,
   or swapoff have removed the shadow from swapcache after we saw the
   shmem swap entry.&lt;/p&gt;
&lt;p&gt;This will send a NULL to workingset_test_recent(). The latter
   purely operates on pointer bits, so it won&amp;#39;t crash - node 0, memcg
   ID 0, eviction timestamp 0, etc. are all valid inputs - but it&amp;#39;s a
   bogus test. In theory that could result in a false &amp;#34;recently
   evicted&amp;#34; count.&lt;/p&gt;
&lt;p&gt;Such a false positive wouldn&amp;#39;t be the end of the world. But for
   code clarity and (future) robustness, be explicit about this case.&lt;/p&gt;
&lt;p&gt;Bail on get_shadow_from_swap_cache() returning NULL.&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: cachestat: fix two shmem bugs&lt;/p&gt;
&lt;p&gt;When cachestat on shmem races with swapping and invalidation, there
are two possible bugs:&lt;/p&gt;
&lt;p&gt;1) A swapin error can have resulted in a poisoned swap entry in the
   shmem inode&amp;#39;s xarray. Calling get_shadow_from_swap_cache() on it
   will result in an out-of-bounds access to swapper_spaces[].&lt;/p&gt;
&lt;p&gt;Validate the entry with non_swap_entry() before going further.&lt;/p&gt;
&lt;p&gt;2) When we find a valid swap entry in the shmem&amp;#39;s inode, the shadow
   entry in the swapcache might not exist yet: swap IO is still in
   progress and we&amp;#39;re before __remove_mapping; swapin, invalidation,
   or swapoff have removed the shadow from swapcache after we saw the
   shmem swap entry.&lt;/p&gt;
&lt;p&gt;This will send a NULL to workingset_test_recent(). The latter
   purely operates on pointer bits, so it won&amp;#39;t crash - node 0, memcg
   ID 0, eviction timestamp 0, etc. are all valid inputs - but it&amp;#39;s a
   bogus test. In theory that could result in a false &amp;#34;recently
   evicted&amp;#34; count.&lt;/p&gt;
&lt;p&gt;Such a false positive wouldn&amp;#39;t be the end of the world. But for
   code clarity and (future) robustness, be explicit about this case.&lt;/p&gt;
&lt;p&gt;Bail on get_shadow_from_swap_cache() returning NULL.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2024-35797</guid>
    </item>
  </channel>
</rss>
