CVE-2024-47679
Linux Btrfs VFS Race Condition
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.
INFO
Published Date :
Oct. 21, 2024, 12:15 p.m.
Last Modified :
Nov. 8, 2024, 4:15 p.m.
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Remotely Exploitable :
No
Impact Score :
3.6
Exploitability Score :
1.0
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2024-47679.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2024-47679 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2024-47679 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Nov. 08, 2024
Action Type Old Value New Value Added Reference kernel.org https://git.kernel.org/stable/c/6cc13a80a26e6b48f78c725c01b91987d61563ef [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/489faddb1ae75b0e1a741fe5ca2542a2b5e794a5 [No types assigned] -
Initial Analysis by [email protected]
Oct. 23, 2024
Action Type Old Value New Value Added CVSS V3.1 NIST AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H Changed Reference Type https://git.kernel.org/stable/c/0eed942bc65de1f93eca7bda51344290f9c573bb No Types Assigned https://git.kernel.org/stable/c/0eed942bc65de1f93eca7bda51344290f9c573bb Patch Changed Reference Type https://git.kernel.org/stable/c/0f8a5b6d0dafa4f533ac82e98f8b812073a7c9d1 No Types Assigned https://git.kernel.org/stable/c/0f8a5b6d0dafa4f533ac82e98f8b812073a7c9d1 Patch Changed Reference Type https://git.kernel.org/stable/c/3721a69403291e2514d13a7c3af50a006ea1153b No Types Assigned https://git.kernel.org/stable/c/3721a69403291e2514d13a7c3af50a006ea1153b Patch Changed Reference Type https://git.kernel.org/stable/c/47a68c75052a660e4c37de41e321582ec9496195 No Types Assigned https://git.kernel.org/stable/c/47a68c75052a660e4c37de41e321582ec9496195 Patch Changed Reference Type https://git.kernel.org/stable/c/540fb13120c9eab3ef203f90c00c8e69f37449d1 No Types Assigned https://git.kernel.org/stable/c/540fb13120c9eab3ef203f90c00c8e69f37449d1 Patch Changed Reference Type https://git.kernel.org/stable/c/6c857fb12b9137fee574443385d53914356bbe11 No Types Assigned https://git.kernel.org/stable/c/6c857fb12b9137fee574443385d53914356bbe11 Patch Changed Reference Type https://git.kernel.org/stable/c/88b1afbf0f6b221f6c5bb66cc80cd3b38d696687 No Types Assigned https://git.kernel.org/stable/c/88b1afbf0f6b221f6c5bb66cc80cd3b38d696687 Patch Added CWE NIST CWE-362 Added CPE Configuration OR *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 2.6.37 up to (excluding) 5.10.227 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.11 up to (excluding) 5.15.168 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.16 up to (excluding) 6.1.113 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.2 up to (excluding) 6.6.54 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.7 up to (excluding) 6.10.13 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.11 up to (excluding) 6.11.2 -
CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Oct. 21, 2024
Action Type Old Value New Value Added 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. Added Reference kernel.org https://git.kernel.org/stable/c/47a68c75052a660e4c37de41e321582ec9496195 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/3721a69403291e2514d13a7c3af50a006ea1153b [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/540fb13120c9eab3ef203f90c00c8e69f37449d1 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/0eed942bc65de1f93eca7bda51344290f9c573bb [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/0f8a5b6d0dafa4f533ac82e98f8b812073a7c9d1 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/6c857fb12b9137fee574443385d53914356bbe11 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/88b1afbf0f6b221f6c5bb66cc80cd3b38d696687 [No types assigned]
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2024-47679 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2024-47679
weaknesses.