CVE-2024-47679 vfs: fix race between evice_inodes() and find_inode()&iput()

High 7.8 Published Updated

A race condition in the Linux kernel VFS layer allows concurrent inode eviction, potentially triggering a kernel bug and causing a denial of service.

Exploited in the wild
Not known
Login needed
Any signed-in user
Attackable
Local or same network only
Victim action needed
Not needed
Fix
Available

What is CVE-2024-47679?

CVE-2024-47679 is a high-severity vulnerability in Linux kernel, published on 21 Oct 2024. It can only be exploited from the same machine or local network, with no action from the victim.

Official description

In the Linux kernel, the following vulnerability has been resolved:

vfs: fix race between evice_inodes() and find_inode()&iput()

Hi, all

Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs.

Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super().

cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set

btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict()

Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput().

To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced.

If there is any misunderstanding, please let me know, thanks.

[1]: https://lore.kernel.org/linux-btrfs/[email protected]/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.

Weakness: CWE-362

Which versions are affected by CVE-2024-47679?

It affects 1 product.

Products include Linux kernel.

How do I fix CVE-2024-47679?

Apply the vendor's patch.

Is CVE-2024-47679 being exploited?

There is no known exploitation of CVE-2024-47679 in the wild and no public exploit code.

All Linux kernel vulnerabilities

Sources

Also known as AZL-50770, AZL-50900, BELL-CVE-2024-47679, DEBIAN-CVE-2024-47679, GHSA-9p2r-69c4-v82v, UBUNTU-CVE-2024-47679.

Is CVE-2024-47679 in your software?

Upload an SBOM and sbomify checks it against every vulnerability here, every day.

Check your SBOMs for free