<?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>Fri, 02 Oct 2026 12:27:45 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-45003 — vfs: Don't evict inode under the inode lru traversing context</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2024-45003</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;vfs: Don&amp;#39;t evict inode under the inode lru traversing context&lt;/p&gt;
&lt;p&gt;The inode reclaiming process(See function prune_icache_sb) collects all
reclaimable inodes and mark them with I_FREEING flag at first, at that
time, other processes will be stuck if they try getting these inodes
(See function find_inode_fast), then the reclaiming process destroy the
inodes by function dispose_list(). Some filesystems(eg. ext4 with
ea_inode feature, ubifs with xattr) may do inode lookup in the inode
evicting callback function, if the inode lookup is operated under the
inode lru traversing context, deadlock problems may happen.&lt;/p&gt;
&lt;p&gt;Case 1: In function ext4_evict_inode(), the ea inode lookup could happen
        if ea_inode feature is enabled, the lookup process will be stuck
	under the evicting context like this:&lt;/p&gt;
&lt;p&gt;1. File A has inode i_reg and an ea inode i_ea
 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru-&amp;gt;i_ea
 3. Then, following three processes running like this:&lt;/p&gt;
&lt;p&gt;PA                              PB
 echo 2 &amp;gt; /proc/sys/vm/drop_caches
  shrink_slab
   prune_dcache_sb
   // i_reg is added into lru, lru-&amp;gt;i_ea-&amp;gt;i_reg
   prune_icache_sb
    list_lru_walk_one
     inode_lru_isolate
      i_ea-&amp;gt;i_state |= I_FREEING // set inode state
     inode_lru_isolate
      __iget(i_reg)
      spin_unlock(&amp;amp;i_reg-&amp;gt;i_lock)
      spin_unlock(lru_lock)
                                     rm file A…&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;vfs: Don&amp;#39;t evict inode under the inode lru traversing context&lt;/p&gt;
&lt;p&gt;The inode reclaiming process(See function prune_icache_sb) collects all
reclaimable inodes and mark them with I_FREEING flag at first, at that
time, other processes will be stuck if they try getting these inodes
(See function find_inode_fast), then the reclaiming process destroy the
inodes by function dispose_list(). Some filesystems(eg. ext4 with
ea_inode feature, ubifs with xattr) may do inode lookup in the inode
evicting callback function, if the inode lookup is operated under the
inode lru traversing context, deadlock problems may happen.&lt;/p&gt;
&lt;p&gt;Case 1: In function ext4_evict_inode(), the ea inode lookup could happen
        if ea_inode feature is enabled, the lookup process will be stuck
	under the evicting context like this:&lt;/p&gt;
&lt;p&gt;1. File A has inode i_reg and an ea inode i_ea
 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru-&amp;gt;i_ea
 3. Then, following three processes running like this:&lt;/p&gt;
&lt;p&gt;PA                              PB
 echo 2 &amp;gt; /proc/sys/vm/drop_caches
  shrink_slab
   prune_dcache_sb
   // i_reg is added into lru, lru-&amp;gt;i_ea-&amp;gt;i_reg
   prune_icache_sb
    list_lru_walk_one
     inode_lru_isolate
      i_ea-&amp;gt;i_state |= I_FREEING // set inode state
     inode_lru_isolate
      __iget(i_reg)
      spin_unlock(&amp;amp;i_reg-&amp;gt;i_lock)
      spin_unlock(lru_lock)
                                     rm file A…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2024-45003</guid>
    </item>
  </channel>
</rss>
