b2sum/cksum `--check`: an over-length BLAKE2b digest in the checksum file aborts the process (exit 134/141)

[leeewee]

When verifying a checksum file (b2sum -c, or cksum -a blake2b --check), uutils derives the BLAKE2b output length from the digest written in the file and passes it straight to the hasher without validating it against the 64-byte maximum. A check line whose digest decodes to more than 64 bytes — for a file that exists — makes blake2b_simd::Params::hash_length fail its assert!(length <= 64) and abort the whole run.

$ mkdir t && cd t
$ echo data > f1                                   # the file named in the check line must exist
$ printf '%s f1\n' "$(printf 'ab%.0s' $(seq 65))" > sums   # 65-byte (130-hex) "digest", filename f1
$ b2sum -c sums
thread 'main' panicked at blake2b_simd-1.0.4/src/lib.rs:239:9:
Bad hash length: 65
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
$ echo $?
134

Any digest length > 64 bytes reproduces it. cksum -a blake2b --check sums takes the same path.

$ cksum -a blake2b --check sums
thread 'main' panicked at blake2b_simd-1.0.4/src/lib.rs:239:9:
Bad hash length: 65
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
$ echo $?
134

GNU b2sum -c rejects the same file gracefully.

$ b2sum -c sums          # GNU coreutils
b2sum: sums: no properly formatted BLAKE2 checksum lines found
$ echo $?
0

Root cause

The --length/-l CLI path is validated (parse_blake_length rejects > 512 bits), but the checksum-file path is not: process_non_algo_based_line sets algo_byte_len = Some(expected_checksum.len()) (src/uucore/src/lib/features/checksum/validate.rs:794) and hands it to SizedAlgoKind::from_unsized, which stores it unchecked (.../checksum/mod.rs:303, Blake2b(l.unwrap_or(..))). Building the digest then calls Blake2b::with_output_bytes(len) (.../features/sum.rs:96) → blake2b_simd hash_length(len), whose assert! panics for len > 64.

[Dijaa]

Repros on 51ed5dc, though a couple of details don't match what I get here.

In a debug build it doesn't hit the blake2b_simd assert. It hits our own
debug_assert! in sum.rs:100 ("GNU doesn't accept BLAKE2b bigger than 64 bytes
long"), exit 101. In release that assert is compiled out, so blake2b_simd's
fires instead, and since the release profile sets panic = "abort" it comes out
as SIGABRT:

thread 'main' panicked at blake2b_simd-1.0.5/src/lib.rs:241:9:
Bad hash length: 65
exit status: 134

Same bug either way. Took me a while to work out why the report said 134 and I
was getting 101.

GNU also exits 1 here, not 0. Same file, GNU coreutils 9.4:

$ b2sum -c sums
b2sum: sums: no properly formatted checksum lines found
exit status: 1

As for where it goes wrong: validate.rs:794 infers the BLAKE2b length straight
from the digest in the file and never runs it through parse_blake_length. The
CLI --length path and the tagged-line path both do. Happy to take this one if
nobody else is on it.