From: Dmitry Kandybka <d.kandybka@xxxxxxxxx> [ 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 <d.kandybka@xxxxxxxxx> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@xxxxxxx> Signed-off-by: Ilya Dryomov <idryomov@xxxxxxxxx> Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx> --- **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@xxxxxxxxxxxxxxx` ### 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
