From e4bf63c976b0e3253f980360b2fe6244092b777c Mon Sep 17 00:00:00 2001
From: Michael Tokarev <mjt@tls.msk.ru>
Date: Thu, 17 Nov 2022 23:51:03 +0300
Subject: [PATCH] fruit: disable useless size_t overflow check
Bug-Debian: http://bugs.debian.org/974868

As has been said several times in
https://bugzilla.samba.org/show_bug.cgi?id=13622 ,
the check 'bandsize > SIZE_MAX/nbands' is useless.  But it
is also wrong, in 2 ways: first, nbands might be 0 (when
no bands has been allocated yet), and second, there's no
point in comparing this with SIZE_MAX, since size_t on 32bit
platforms is a 32bit integer, while bandsize is off_t which
is 64bits (samba always enables LFS).

This check causes the module to fail when bandsize*nbands
exceeds 32bits, which has been reported for example at
https://bugs.debian.org/974868 .

Whole thing can't overflow because it is already guarded
by time_machine_max_size.  Or at the very least, by current
disk sizes... :)

Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
---
 source3/modules/vfs_fruit.c | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/source3/modules/vfs_fruit.c b/source3/modules/vfs_fruit.c
index 4058d4834e7..8e31e74f2a6 100644
--- a/source3/modules/vfs_fruit.c
+++ b/source3/modules/vfs_fruit.c
@@ -5273,17 +5273,6 @@ static bool fruit_tmsize_do_dirent(vfs_handle_struct *handle,
 		return true;
 	}
 
-	/*
-	 * Arithmetic on 32-bit systems may cause overflow, depending on
-	 * size_t precision. First we check its unlikely, then we
-	 * force the precision into target off_t, then we check that
-	 * the total did not overflow either.
-	 */
-	if (bandsize > SIZE_MAX/nbands) {
-		DBG_ERR("tmsize potential overflow: bandsize [%zu] nbands [%zu]\n",
-			bandsize, nbands);
-		return false;
-	}
 	tm_size = (off_t)bandsize * (off_t)nbands;
 
 	if (state->total_size + tm_size < state->total_size) {
-- 
2.30.2

