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 84AAF224895; Mon, 9 Jun 2025 22:54:16 +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=1749509656; cv=none; b=svevhk+LVtT9DpK91mQ0EzrNVzt7Gr4dxbxcS5YjeJKFuTdvlx65KYkJIS6cOZGSF5HgcVLw8yYzjCPbt5wf5HM7pO7HjfjeveeItHDZ36yUjtqUSqJRXtOHanA1ilid8StovDoDiRnPgDmGaruI4GrTB4xgDWAzFlHJItzeCtM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749509656; c=relaxed/simple; bh=d//prd4TDzf52xdMCxuP7Cz3n3b6qoSH6Nasajdv0jw=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Hxo6kdLqXZHK5Re9U8xCfXlUABZ6ModryQyRMoPHpjbpo7KMLHkPwneAKYKys59i5S1UpT3CQjb5Swr6LGWBo6qIw0TMVdBFOQXI1ovoNIQAl0OPNwA9sRIVLt7IKM6Vf1Cc2Vxm5tgHvpR6d18xGtOtTFfZPuxsigMJQ1I+oDo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=M/GLvrXx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="M/GLvrXx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80D00C4CEF3; Mon, 9 Jun 2025 22:54:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749509656; bh=d//prd4TDzf52xdMCxuP7Cz3n3b6qoSH6Nasajdv0jw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=M/GLvrXxeivtGZP3tAjSfDbP5aL4erqHKiVANq5dTbb0ozl179ohRia2h9KT0GBLd 3lypoomD8TXBVVNmhxtoDBTbOZkHoyIrsBJV4bvI7POOgKIsRmqNtHAmx1lsg4xWEM 66hE+91oUKQboSfkZnu4KyqlB5qe5WhZEQVWR5b6SSf0OCYA6UMSHz8B5iG6TwSuq6 PXbK9CQl0+F3RRJVcaHoPM5iLKk654wv/DoOenU8sH0Q/jB40UrVdT5aV9HBafsVqO 4WioBUDBN5T67grU8+97dACPrtMrV3MxOKXayYXDos/3Qv83rc1M3rIh6X5MSkQ7Lx YhnUQXTy057Qg== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Dmitry Kandybka , Viacheslav Dubeyko , Ilya Dryomov , Sasha Levin , xiubli@redhat.com, ceph-devel@vger.kernel.org Subject: [PATCH AUTOSEL 5.10 3/4] ceph: fix possible integer overflow in ceph_zero_objects() Date: Mon, 9 Jun 2025 18:54:08 -0400 Message-Id: <20250609225410.1444715-3-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250609225410.1444715-1-sashal@kernel.org> References: <20250609225410.1444715-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 5.10.238 Content-Transfer-Encoding: 8bit From: Dmitry Kandybka [ Upstream commit 0abd87942e0c93964e93224836944712feba1d91 ] In 'ceph_zero_objects', promote 'object_size' to 'u64' to avoid possible integer overflow. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Kandybka Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin --- **YES** This commit should be backported to stable kernel trees. Here's my detailed analysis: ## Why This Should Be Backported ### 1. **Clear Bug Fix with User Impact** The commit fixes a real integer overflow vulnerability in `ceph_zero_objects()` where `s32 object_size` is multiplied by `s32 stripe_count` to calculate `u64 object_set_size`. When the layout values exceed 2^31, the multiplication can underflow, leading to: - Incorrect loop bounds in the zeroing logic - Potential infinite loops or premature termination - Data integrity issues during hole punching operations - Incorrect `do_div()` operations ### 2. **Affects Critical Kernel Functionality** This bug impacts core filesystem operations that users depend on: - `fallocate()` system call with `FALLOC_FL_PUNCH_HOLE` - File sparse operations used by databases, VMs, backup tools - Copy-on-write optimizations in Ceph filesystems ### 3. **Small, Contained, and Low-Risk Fix** The code change is minimal and safe: ```c - u64 object_set_size = object_size * stripe_count; + u64 object_set_size = (u64) object_size * stripe_count; ``` This fix: - Promotes `object_size` to `u64` before multiplication, preventing overflow - Has no functional side effects beyond fixing the bug - Maintains consistency with the underlying `u32` data types in `ceph_file_layout` - Cannot introduce regressions ### 4. **Follows Stable Tree Criteria** - **Important bugfix**: Prevents potential data corruption and system instability - **Minimal risk**: Single-line change with no architectural impact - **Confined scope**: Only affects Ceph filesystem's hole punching logic - **No new features**: Pure defensive fix ### 5. **Matches Successful Backport Pattern** This commit is very similar to **Similar Commit #1** (marked YES for backport) which also: - Fixed a type promotion bug affecting critical operations - Had minimal code changes with clear safety benefits - Addressed potential data integrity issues - Was explicitly marked with `Cc: stable@vger.kernel.org` ### 6. **Proactive Hardening Value** While the bug requires specific conditions to trigger (large object sizes or stripe counts), backporting provides: - Defense against potential malicious layouts from compromised metadata servers - Protection for users with unusual but valid filesystem configurations - General robustness improvement for production systems The fix has no downside risk and provides meaningful protection against a real integer overflow scenario that could affect data integrity in Ceph filesystems. fs/ceph/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ceph/file.c b/fs/ceph/file.c index d4974c652e8e4..c1eafff45b194 100644 --- a/fs/ceph/file.c +++ b/fs/ceph/file.c @@ -2034,7 +2034,7 @@ static int ceph_zero_objects(struct inode *inode, loff_t offset, loff_t length) s32 stripe_unit = ci->i_layout.stripe_unit; s32 stripe_count = ci->i_layout.stripe_count; s32 object_size = ci->i_layout.object_size; - u64 object_set_size = object_size * stripe_count; + u64 object_set_size = (u64) object_size * stripe_count; u64 nearly, t; /* round offset up to next period boundary */ -- 2.39.5