Executive Summary

Informations
Name CVE-2024-45003 First vendor Publication 2024-09-04
Vendor Cve Last vendor Modification 2024-11-05

Security-Database Scoring CVSS v3

Cvss vector : CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Overall CVSS Score 4.7
Base Score 4.7 Environmental Score 4.7
impact SubScore 3.6 Temporal Score 4.7
Exploitabality Sub Score 1
 
Attack Vector Local Attack Complexity High
Privileges Required Low User Interaction None
Scope Unchanged Confidentiality Impact None
Integrity Impact None Availability Impact High
Calculate full CVSS 3.0 Vectors scores

Security-Database Scoring CVSS v2

Cvss vector :
Cvss Base Score N/A Attack Range N/A
Cvss Impact Score N/A Attack Complexity N/A
Cvss Expoit Score N/A Authentication N/A
Calculate full CVSS 2.0 Vectors scores

Detail

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

vfs: Don't evict inode under the inode lru traversing context

The inode reclaiming process(See function prune_icache_sb) collects all reclaimable inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen.

Case 1: In function ext4_evict_inode(), the ea inode lookup could happen
if ea_inode feature is enabled, the lookup process will be stuck
under the evicting context like this:

1. File A has inode i_reg and an ea inode i_ea
2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
3. Then, following three processes running like this:

PA PB
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// i_reg is added into lru, lru->i_ea->i_reg
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
i_ea->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(i_reg)
spin_unlock(&i_reg->i_lock)
spin_unlock(lru_lock)
rm file A
i_reg->nlink = 0
iput(i_reg) // i_reg->nlink is 0, do evict
ext4_evict_inode
ext4_xattr_delete_inode
ext4_xattr_inode_dec_ref_all
ext4_xattr_inode_iget
ext4_iget(i_ea->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(i_ea) ----? AA deadlock
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&i_ea->i_state)

Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file
deleting process holds BASEHD's wbuf->io_mutex while getting the
xattr inode, which could race with inode reclaiming process(The
reclaiming process could try locking BASEHD's wbuf->io_mutex in
inode evicting function), then an ABBA deadlock problem would
happen as following:

1. File A has inode ia and a xattr(with inode ixa), regular file B has
inode ib and a xattr.
2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
3. Then, following three processes running like this:

PA PB PC
echo 2 > /proc/sys/vm/drop_caches
shrink_slab
prune_dcache_sb
// ib and ia are added into lru, lru->ixa->ib->ia
prune_icache_sb
list_lru_walk_one
inode_lru_isolate
ixa->i_state |= I_FREEING // set inode state
inode_lru_isolate
__iget(ib)
spin_unlock(&ib->i_lock)
spin_unlock(lru_lock)
rm file B
ib->nlink = 0
rm file A
iput(ia)
ubifs_evict_inode(ia)
ubifs_jnl_delete_inode(ia)
ubifs_jnl_write_inode(ia)
make_reservation(BASEHD) // Lock wbuf->io_mutex
ubifs_iget(ixa->i_ino)
iget_locked
find_inode_fast
__wait_on_freeing_inode(ixa)
| iput(ib) // ib->nlink is 0, do evict
| ubifs_evict_inode
| ubifs_jnl_delete_inode(ib)
? ubifs_jnl_write_inode
ABBA deadlock ?-----make_reservation(BASEHD)
dispose_list // cannot be executed by prune_icache_sb
wake_up_bit(&ixa->i_state)

Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING to pin the inode in memory while inode_lru_isolate( ---truncated---

Original Source

Url : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-45003

CWE : Common Weakness Enumeration

% Id Name
100 % CWE-667 Insufficient Locking

CPE : Common Platform Enumeration

TypeDescriptionCount
Application 8
Os 3649

Sources (Detail)

https://git.kernel.org/stable/c/03880af02a78bc9a98b5a581f529cf709c88a9b8
https://git.kernel.org/stable/c/2a0629834cd82f05d424bbc193374f9a43d1f87d
https://git.kernel.org/stable/c/3525ad25240dfdd8c78f3470911ed10aa727aa72
https://git.kernel.org/stable/c/437741eba63bf4e437e2beb5583f8633556a2b98
https://git.kernel.org/stable/c/9063ab49c11e9518a3f2352434bb276cc8134c5f
https://git.kernel.org/stable/c/b9bda5f6012dd00372f3a06a82ed8971a4c57c32
https://git.kernel.org/stable/c/cda54ec82c0f9d05393242b20b13f69b083f7e88
Source Url

Alert History

If you want to see full details history, please login or register.
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Date Informations
2025-01-08 03:04:58
  • Multiple Updates
2025-01-07 03:04:31
  • Multiple Updates
2024-12-25 03:03:09
  • Multiple Updates
2024-12-12 03:06:05
  • Multiple Updates
2024-11-23 03:03:06
  • Multiple Updates
2024-11-22 03:01:16
  • Multiple Updates
2024-11-20 02:59:36
  • Multiple Updates
2024-11-13 21:21:59
  • Multiple Updates
2024-11-09 00:28:26
  • Multiple Updates
2024-11-05 13:27:50
  • Multiple Updates
2024-10-26 02:57:18
  • Multiple Updates
2024-10-25 02:59:11
  • Multiple Updates
2024-10-23 02:58:22
  • Multiple Updates
2024-10-09 21:27:49
  • Multiple Updates
2024-09-16 00:27:31
  • Multiple Updates
2024-09-05 17:27:24
  • Multiple Updates
2024-09-05 00:27:25
  • First insertion