From 496611f476c79ae51250f2d4664dff7798e2861b Mon Sep 17 00:00:00 2001 From: Andrea Mazzoleni Date: Wed, 18 Nov 2015 23:02:21 +0100 Subject: [PATCH] Fix an integer overflow when computing the size of a deleted entry This bug prevented SnapRAID to read a valid content file, in case a deleted entry bigger than 4 GB was present. This could be reproduced deleting a file bigger than 4 GB and then sync. --- HISTORY | 9 +++++++++ cmdline/state.c | 2 +- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/HISTORY b/HISTORY index 59be55ae..d1510476 100644 --- a/HISTORY +++ b/HISTORY @@ -3,6 +3,15 @@ SnapRAID HISTORY 9.1 2015/11 =========== + * Fixes a bug when reading a content file with a deleted entry + bigger than 4 GB. This was a regression introduced in + version 9.0 that could result in the impossibility to read + a valid content file, after a deletion of a file bigger than 4 GB + in the array. + If this happened to you, just upgrading to 9.1 fixes the issue, + and it allows you to continue to work. + Note that this bug only prevented to run 9.0, but your data was still + protected and could have been recovered using the versions 8.1 or 9.1. * In Winwdows disables the file zero check requring the --force-zero option. This check is intended for possible case using ext3/4 in Linux, and there is no evidence that in Windows it's possible at all. diff --git a/cmdline/state.c b/cmdline/state.c index 335a0e9a..eb753433 100644 --- a/cmdline/state.c +++ b/cmdline/state.c @@ -2012,7 +2012,7 @@ static void state_read_content(struct snapraid_state* state, const char* path, S /* if it's a run of deleted blocks */ /* allocate a fake deleted file */ - deleted = file_alloc(state->block_size, "", v_count * state->block_size, 0, 0, 0, 0); + deleted = file_alloc(state->block_size, "", v_count * (data_off_t)state->block_size, 0, 0, 0, 0); /* mark the file as deleted */ file_flag_set(deleted, FILE_IS_DELETED);