vfs_fruit overflow checks on armhf with large Time Machine backups

ArtMG smblock at artmg.org
Mon May 25 19:37:54 UTC 2020

Hi, following the patch you guys helped me create and get into v4.12.1, I got my Time Machine backups working, at first. https://gitlab.com/samba-team/samba/-/commit/b8ef341f6b537ce23262ca191f4f55a6508a0854

Now, however, since the total volume of data stored in the 'bands' has grown to 100s of GB I am getting failure because of the checks on precision, and I am not sure how to handle this. This is on armhf (Raspbian), with the vfs_fruit module – the issue occurs in ``fruit_tmsize_do_dirent``where there is an overflow check on the calculation of `tm_size.`

	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;

I get the error "tmsize potential overflow: bandsize [8388608] nbands [36980]", failing because the overflow check is based on SIZE_MAX, which on my machine is 32 bits.

Checking if size of size_t == 4 : ok
Checking if size of off_t == 8 : ok

However this is an unreliable meter of overflow risk in this case, because tm_size is declared as an off_t, which is actually 64 bits as you see above. Unfortunately, to maintain the overflow check, I cannot find a reliable way of encoding OFF_MAX. Also I fear that LLONG_MAX might not be a reliable on a system where off_t is only a 32-bit signed integer. So I am stuck for ideas of how I should recode this to allow it to work for me, but successfully avoid overflow when compiled elsewhere.

I welcome advice from seasoned contributors as to the safest way to patch this. 
Thanks, Art

More information about the samba-technical mailing list