boxscore/security
CVE · referencelatest edition

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.

CVE-2024-47679MEDIUM
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).
CWE-362 · CNA: Linux · CVSS v3.1 · 11 references · NVD status: Modified

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
DateEventDetail
September 30, 2024ReservedReserved by Linux
October 21, 2024PublishedPublished (CNA: Linux)
August 4, 2026RESCOREDRESCORED — CVE-2024-47679 (Linux). CVSS 7.8 → 4.7 (NVD).

Affected

Affected products and packages — 2 rows
VendorProduct / PackageEcosystemVersion introducedFixed
LinuxLinux63997e98a3be68d7cec806d22bf9b02b2e1daabb
LinuxLinux2.6.374.19.323

Weaknesses

CWE-362

References (11)

Related

Authoritative record: CVE-2024-47679 at cve.org

Vendors: linux

Weaknesses: CWE-362

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.