From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 871751E7647 for ; Wed, 4 Sep 2024 19:58:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725479884; cv=none; b=j6KpnlEATQqkmhy4kbam++CMjdtPM2AOpT4Mrt0i9u4qVmUFOnKB578+Xn9n7liQkizh1+mdzK4r82+5kqpL8uyk0+ua/Usl6e/Sv6j3eeCJggtre/NLO8QIpMNlCTA5FTRB+I7Er4Hew8UkTP/ubGlHBsNv4atCnwayabYoETw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725479884; c=relaxed/simple; bh=iiDXNjJWhvOVOhmY9P13YPC/IjmfcU4m3PpPkbsww4Y=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=njwp2qfDYozDA1B7bswVGeBzR3TeAORqFyQLG49yv3kWe+lFIZLytsRHAjQAw0UOansD3FdWQjvREch5y3gAOodBWjy5H/+e1Pd92LY2kRDvY5+W16QcZR49CKdF2pNXcRxX9LilGyITs4Ae1VMKaO7c7KkAQsmknPo1NebGHGw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=npNMrXWQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="npNMrXWQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0FA6AC4CEC2; Wed, 4 Sep 2024 19:58:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1725479884; bh=iiDXNjJWhvOVOhmY9P13YPC/IjmfcU4m3PpPkbsww4Y=; h=From:To:Cc:Subject:Date:Reply-to:From; b=npNMrXWQJL8Ha5ZLhxfWqAuI3vlsK233qRall+9Z7cNpSlNpr5P1vBGa/S3WQrTMb fT3Igh8aX2XEEV0gVp4QEOkVCQKGxFZyVSo+01KG77SUO8gMyGGg3IX2yviIbB3UKb CSVDh4iWBwz+gphlB2zB2e2SLRmZgT9n1wwmkYx0= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2024-45003: vfs: Don't evict inode under the inode lru traversing context Date: Wed, 4 Sep 2024 21:57:08 +0200 Message-ID: <2024090450-CVE-2024-45003-3bc2@gregkh> X-Mailer: git-send-email 2.46.0 Precedence: bulk X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Reply-to: , X-Developer-Signature: v=1; a=openpgp-sha256; l=6734; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=iiDXNjJWhvOVOhmY9P13YPC/IjmfcU4m3PpPkbsww4Y=; b=owGbwMvMwCRo6H6F97bub03G02pJDGk3djd5n049l3ifwW3Pg5ffZJoivxu/NVdjqFuqcJU9+ s68NU0WHbEsDIJMDLJiiixftvEc3V9xSNHL0PY0zBxWJpAhDFycAjAReUGGORyXl584pb2Uo1sx xttq3Z/lTDN+1jDMT7g4yUen2Y3HNjHQd+X+mrTJ7ctPAAA= X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Description =========== 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() reclaims its pages instead of using ordinary inode reference. This way inode deletion cannot be triggered from inode_lru_isolate() thus avoiding the deadlock. evict() is made to wait for I_LRU_ISOLATING to be cleared before proceeding with inode cleanup. The Linux kernel CVE team has assigned CVE-2024-45003 to this issue. Affected and fixed versions =========================== Issue introduced in 4.13 with commit e50e5129f384 and fixed in 5.4.283 with commit 3525ad25240d Issue introduced in 4.13 with commit e50e5129f384 and fixed in 5.10.225 with commit 03880af02a78 Issue introduced in 4.13 with commit e50e5129f384 and fixed in 5.15.166 with commit cda54ec82c0f Issue introduced in 4.13 with commit e50e5129f384 and fixed in 6.1.107 with commit 437741eba63b Issue introduced in 4.13 with commit e50e5129f384 and fixed in 6.6.48 with commit b9bda5f6012d Issue introduced in 4.13 with commit e50e5129f384 and fixed in 6.10.7 with commit 9063ab49c11e Issue introduced in 4.13 with commit e50e5129f384 and fixed in 6.11-rc4 with commit 2a0629834cd8 Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2024-45003 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: fs/inode.c include/linux/fs.h Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/3525ad25240dfdd8c78f3470911ed10aa727aa72 https://git.kernel.org/stable/c/03880af02a78bc9a98b5a581f529cf709c88a9b8 https://git.kernel.org/stable/c/cda54ec82c0f9d05393242b20b13f69b083f7e88 https://git.kernel.org/stable/c/437741eba63bf4e437e2beb5583f8633556a2b98 https://git.kernel.org/stable/c/b9bda5f6012dd00372f3a06a82ed8971a4c57c32 https://git.kernel.org/stable/c/9063ab49c11e9518a3f2352434bb276cc8134c5f https://git.kernel.org/stable/c/2a0629834cd82f05d424bbc193374f9a43d1f87d