Reference page — cumulative record through Wednesday, August 19, 2026 UTC. Reference pages update as the archive grows; only dated daily editions are immutable pages of record.
Linux Linux — vfs: fix race between evice_inodes() and find_inode()&iput()
AV AC PR UI S C I A CVSS EPSS %ile KEV
L H L N U N N H 4.7 .0020 10.6 —
AFFECTED
Product Versions Fixed
Linux 63997e98a3be68d7cec806d22bf9b02b2e1daabb – —
Linux 2.6.37 – 4.19.323
TIMELINE
Sep 30 Reserved by Linux
Oct 21 Published (CNA: Linux)
Aug 4 RESCORED — CVE-2024-47679 (Linux). CVSS 7.8 → 4.7 (NVD).
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/000000000000eabe1d0619c48986@google.com/
[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()
return false when I reproduced the bug.
Lifecycle
Complete event history — 3 events, chronological
| Date | Event | Detail |
| September 30, 2024 | Reserved | Reserved by Linux |
| October 21, 2024 | Published | Published (CNA: Linux) |
| August 4, 2026 | RESCORED | RESCORED — CVE-2024-47679 (Linux). CVSS 7.8 → 4.7 (NVD). |
Affected
Affected products and packages — 2 rows
| Vendor | Product / Package | Ecosystem | Version introduced | Fixed |
| Linux | Linux | — | 63997e98a3be68d7cec806d22bf9b02b2e1daabb | — |
| Linux | Linux | — | 2.6.37 | 4.19.323 |
About this page
This is a reference page, not a dated page of record. It assembles the complete lifecycle of CVE-2024-47679 from the CVE Program record, NVD enrichment, the CISA KEV catalog, EPSS, and OSV advisories. The box score's numbers (CVSS, EPSS, KEV status) are current as of Wednesday, August 19, 2026 UTC and are re-derived as the archive grows; only dated daily editions are immutable pages of record. The authoritative source for this identifier is cve.org.