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.

Metrics

No CVSS v4.0

Attack Vector Local

Attack Complexity High

Privileges Required Low

Scope Unchanged

Confidentiality Impact None

Integrity Impact None

Availability Impact High

User Interaction None

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

Exploitation none

Automatable no

Technical Impact partial

Affected Vendors & Products

Vendors Products
Linux
  • Linux Kernel

Configuration 1 [-]

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*

No data.

References
Link Providers
https://git.kernel.org/stable/c/0eed942bc65de1f93eca7bda51344290f9c573bb cve-icon cve-icon
https://git.kernel.org/stable/c/0f8a5b6d0dafa4f533ac82e98f8b812073a7c9d1 cve-icon cve-icon
https://git.kernel.org/stable/c/3721a69403291e2514d13a7c3af50a006ea1153b cve-icon cve-icon
https://git.kernel.org/stable/c/47a68c75052a660e4c37de41e321582ec9496195 cve-icon cve-icon
https://git.kernel.org/stable/c/489faddb1ae75b0e1a741fe5ca2542a2b5e794a5 cve-icon cve-icon
https://git.kernel.org/stable/c/540fb13120c9eab3ef203f90c00c8e69f37449d1 cve-icon cve-icon
https://git.kernel.org/stable/c/6c857fb12b9137fee574443385d53914356bbe11 cve-icon cve-icon
https://git.kernel.org/stable/c/6cc13a80a26e6b48f78c725c01b91987d61563ef cve-icon cve-icon
https://git.kernel.org/stable/c/88b1afbf0f6b221f6c5bb66cc80cd3b38d696687 cve-icon cve-icon
https://lore.kernel.org/linux-cve-announce/2024102106-CVE-2024-47679-e793@gregkh/T cve-icon
https://nvd.nist.gov/vuln/detail/CVE-2024-47679 cve-icon
https://www.cve.org/CVERecord?id=CVE-2024-47679 cve-icon
History

Fri, 08 Nov 2024 16:00:00 +0000

Type Values Removed Values Added
References

Wed, 23 Oct 2024 15:15:00 +0000

Type Values Removed Values Added
First Time appeared Linux
Linux linux Kernel
Weaknesses CWE-362
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
Metrics cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

 cvssV3_1

{'score': 4.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H'}

Tue, 22 Oct 2024 01:30:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

 cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate

Mon, 21 Oct 2024 13:15:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Mon, 21 Oct 2024 12:00:00 +0000

Type Values Removed Values 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/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.
Title vfs: fix race between evice_inodes() and find_inode()&iput()
References
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published: 2024-10-21T11:53:22.469Z

Updated: 2024-11-08T15:56:10.165Z

Reserved: 2024-09-30T16:00:12.939Z

Link: CVE-2024-47679

cve-icon Vulnrichment

Updated: 2024-10-21T13:07:37.060Z

cve-icon NVD

Status : Modified

Published: 2024-10-21T12:15:04.920

Modified: 2024-11-08T16:15:24.843

Link: CVE-2024-47679

cve-icon Redhat

Severity : Moderate

Publid Date: 2024-10-21T00:00:00Z

Links: CVE-2024-47679 - Bugzilla