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