]> git.ipfire.org Git - thirdparty/rsync.git/commit
rsync.h: lower MAX_WIRE_DEL_STAT to avoid signed-int overflow in read_del_stats
authorAndrew Tridgell <andrew@tridgell.net>
Thu, 14 May 2026 04:45:21 +0000 (14:45 +1000)
committerAndrew Tridgell <andrew@tridgell.net>
Wed, 20 May 2026 00:01:22 +0000 (10:01 +1000)
commitc79cb81a4f07770723b73e85bf6088fe64adc9cd
tree4b0c3a0bb7a356b3ce9f43955c4ebd69fd71df93
parent650643109e6e7f92b9c0fd4f947502f5636803e4
rsync.h: lower MAX_WIRE_DEL_STAT to avoid signed-int overflow in read_del_stats

read_del_stats() in main.c accumulates 5 wire-supplied counts into
the int32 stats.deleted_files field:

    stats.deleted_files  = read_varint_bounded(..., MAX_WIRE_DEL_STAT, ...);
    stats.deleted_files += stats.deleted_dirs     = ...;
    stats.deleted_files += stats.deleted_symlinks = ...;
    stats.deleted_files += stats.deleted_devices  = ...;
    stats.deleted_files += stats.deleted_specials = ...;

With the previous MAX_WIRE_DEL_STAT = 2^30 (1.07 GB) the worst-case
sum is 5 * 2^30 = 5.37 GB; three maximal values already exceed
INT32_MAX = 2.15 GB on the third "+=", triggering signed integer
overflow (C99 6.5/5 -- undefined behaviour, the compiler may assume
it cannot happen and elide subsequent checks).

The bound was introduced in f0155902 ("defence-in-depth: bound
wire-supplied counts and lengths") with a commit message claiming
"per-summand cap so the total can't overflow", but 2^30 * 5 does
overflow.  Lower the per-summand cap to 2^28 (= 268M) so the worst
case is 5 * 2^28 = 1.34 GB < INT32_MAX with margin.  2^28 deletions
per category is still vastly above any plausible real transfer.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
rsync.h