From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794064539; b=mNQM783zl2s9W0epe0JEtph0QmwayM/K16t7RBHcN0wHu/ldEwFdZQFcYhx/yRyYY1IG W5fXAcwqHAzjEjSXcfdQI087O3yYKyaBpz8fUNQn1+A/IZ/JhMnkBJe4lBz4b9ZwfFdMS jd6ZSDVyp2qP3F0g10EM7vcT1Uo8/gpvxQnEUc32+zZf0Z8dGI2Uv+I0Bq6aJA01yUudN YvmbKCBxJdtq3R0C0XJcZ441HdrQe3hinVTYo5lQiJlUaAqiILJpAUqUGl5Rdnfc6sMUq e5criUp4LoITJez1BcWl6wbmVYHpKjvwqS7vTF49MdI/EccnbvDQ4iAylBZoNHLMOnA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794064539; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=Cc0zy/lBOPK57RhANV36qChr64qO003fM8LQ8S82AU4=; b=e9OUTboFx23YrXxcWX2nNAER+QkK2n/iCYzZHwW84vFeSUBNAy9c3imxxxXZ447ku+Wb Z9qWS2uq6+TSceg+EbvcStQNd2s/IFL8cCSN3prEbHgMnSNoFHFsjpCnTonVVGgXKXta1 r9S0NMxBgH4cuowg6puFLiB0jBQh18oAaMKMBmTpnw8MPaya+ilzBwmTmqlWvH1uDgiCM pBMtATXdRPwKlPH1qJ2i9lKhe5B4I55DsxXvLBcJEBBBXZD3VEpmxpZGLyG5kA9y9y0vJ iryJEpD9oAUccCjjmqjPyniJPbQPLBcfDrKw/SpjQ2RtFqQyiNnZx+52EItpUA9C7dQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=F4vd42nn; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 16486606B8A6; Sat, 7 Nov 2026 15:15:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=F4vd42nn Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB5271F008A6; Sat, 7 Nov 2026 15:15:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1794064538; bh=Cc0zy/lBOPK57RhANV36qChr64qO003fM8LQ8S82AU4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=F4vd42nnXNvVvNtATJqS0DF8uhN+5rJo/5tCGq9tEtT6usMSqr4t8zo0D087jULav JoQ6Uz1+qX7vqr6ez7RKsw56BxORPVRAA5OJICz34F0c3fhdwaJUS8JTFkEmQui020 DjqkZAMdSTNdBkK0sXtdzrNLTME9zuStjocy1nuI= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, "Theodore Tso" , Andreas Dilger , Baokun Li , Jan Kara , Ojaswin Mujoo , "Ritesh Harjani (IBM)" , Zhang Yi , Jinjie Ruan , Sasha Levin Subject: [PATCH 7.3 0566/1257] ext4: fix out-of-bounds read in ext4_get_group_info() Date: Sat, 7 Nov 2026 08:47:42 -0500 Message-ID: <20261107134954.994938191@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261107134939.434104957@linuxfoundation.org> References: <20261107134939.434104957@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 7.3-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jinjie Ruan [ Upstream commit b067d3c1f90b536e9aa9f48b19580475a0b34f0f ] A plain read of s_groups_count in ext4_get_group_info() allows CPU load-load reordering. On weak memory models, speculative prefetch of s_group_info prior to the boundary check could lead to an out-of-bounds read if a concurrent online resize expands the array and increments s_groups_count. The data race occurs between the ioctl configuration path (holding the resize lock via ext4_resize_begin) and the lockless metadata lookup path: CPU 0 (Writer, Resize Lock) CPU 1 (Reader, Lockless) --------------------------- ------------------------ ext4_ioctl() [EXT4_IOC_GROUP_ADD] ext4_ioctl_group_add() ext4_resize_begin() // Takes lock ext4_group_add() ext4_mb_alloc_groupinfo() // Publishes expanded array via RCU rcu_assign_pointer(s_group_info, ...) ext4_flex_group_add() ext4_update_super() ext4_get_group_info() // Speculative / out-of-order read [Loads old/smaller s_group_info pointer] [Plain C store / smp_wmb()] sbi->s_groups_count += ...; // Reads new s_groups_count, // boundary check passes if (group >= s_groups_count) // Out-of-bounds array access! sbi_array_rcu_deref(..., s_group_info) Fix this by using ext4_get_groups_count() to enforce acquire semantics. Cc: stable@vger.kernel.org Cc: "Theodore Ts'o" Cc: Andreas Dilger Cc: Baokun Li Cc: Jan Kara Cc: Ojaswin Mujoo Cc: "Ritesh Harjani (IBM)" Cc: Zhang Yi Fixes: 5354b2af3406 ("ext4: allow ext4_get_group_info() to fail") Link: https://sashiko.dev/#/patchset/20260825095422.3166067-1-ruanjinjie%40huawei.com Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Signed-off-by: Jinjie Ruan Link: https://patch.msgid.link/20260902074805.398540-8-ruanjinjie@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin --- fs/ext4/balloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c index 52f4c5169f914..778fe8788f06e 100644 --- a/fs/ext4/balloc.c +++ b/fs/ext4/balloc.c @@ -329,7 +329,7 @@ struct ext4_group_info *ext4_get_group_info(struct super_block *sb, struct ext4_group_info **grp_info; long indexv, indexh; - if (unlikely(group >= EXT4_SB(sb)->s_groups_count)) + if (unlikely(group >= ext4_get_groups_count(sb))) return NULL; if (unlikely(!EXT4_SB(sb)->s_group_info)) return NULL; -- 2.53.0