split: arithmetic overflow (overflow-checks) on a huge `--numeric-suffixes`/`--hex-suffixes` start value

[leeewee]

split auto-computes the suffix length from the suffix start value (--numeric-suffixes=N / --hex-suffixes=N) and the number of output chunks (-n/--number). The computation adds them as start as u64 + chunks with no range check.

coreutils/src/uu/split/src/filenames.rs

Lines 167 to 168 in 21d4e96

	start = usize::from_str_radix(opt, 16)
	.map_err(|_| SuffixError::NotParsable(opt.to_owned()))?;

coreutils/src/uu/split/src/filenames.rs

Lines 200 to 204 in 21d4e96

	if let Strategy::Number(number_type) = strategy {
	let chunks = number_type.num_chunks();
	let required_length = ((start as u64 + chunks) as f64)
	.log(stype.radix() as f64)
	.ceil() as usize;

A start value near u64::MAX makes that add overflow, panicking with attempt to add with overflow under -C overflow-checks (exit 134). GNU rejects an out-of-range start value without crashing.

$ split -n 5 --numeric-suffixes=18446744073709551615 /dev/null
thread 'main' panicked at src/uu/split/src/filenames.rs:202:36:
attempt to add with overflow
$ echo $?
134

--hex-suffixes reaches the same add — but its value is parsed in base 16 (usize::from_str_radix(opt, 16)), so use a hex start near u64::MAX (0xFFFFFFFFFFFFFFFF):

$ split -n 5 --hex-suffixes=ffffffffffffffff /dev/null
thread 'main' panicked at src/uu/split/src/filenames.rs:202:36:
attempt to add with overflow
$ echo $?
134

The chunk count operand overflows the same add just as well — a huge -n with any nonzero start:

$ split -n 18446744073709551615 --numeric-suffixes=5 /dev/null
thread 'main' panicked at src/uu/split/src/filenames.rs:202:36:
attempt to add with overflow
$ echo $?
134