#396 fuzzy finds

[Robert McMahon]

G'day Bob,

Quick follow-up to my earlier static-analysis note. I wired up a small libFuzzer harness set (clang -fsanitize=fuzzer,address,undefined) around iperf2's self-contained parsers and let them run. Each harness links the real code, so these are all reproducible against a stock build. Findings below, terse — happy to send patches or the harnesses themselves.

Confirmed with a reproducing input (found in seconds each):

1. src/markov.c:152 / :160 / :167 — heap buffer-overflow (write)
   markov_graph_init() — a malformed --markov braket string desyncs the strtok/pointer-arithmetic row/column accounting and writes a struct markov_entry field past the allocated row. This is the item from my last note; fuzzing confirms it's an
   out-of-bounds write, not just a read.
   Repro (bytes): 3c 32 35 36 7c 20 30 2e 31 2c 30 2e 37 2c 30 00 00 00 00 34 2c 30 2e 34 2c 30 2e 32 — i.e. <256| 0.1,0.7,0 + 4 NUL bytes + 4,0.4,0.2.

2. src/histogram.c:345 (parse_bins_to_cdf), sized by :405 (count_bin_entries) — heap buffer-overflow (write)
   The caller sizes out[] by counting ;, but the parser's sscanf("%d:%u") also accepts whitespace / a +/- sign as a separator, so it writes more emd_point entries than were allocated.
   Repro: 1:2+3:4;5:6

3. src/histogram.c:437 (histogram_emd_against_baseline) — same overflow, reachable via a file
   The --histogram-baseline file's bins field (CSV field 19) feeds the same parse_bins_to_cdf, so a crafted baseline file triggers #2. Flagging the vector; the file's own CSV line reader held up otherwise.

4. src/checksums.c:222 (udpchecksum), call site src/Server.cpp Server::L2_processing — heap buffer-overflow (read)
   The checksum loop trusts udplen (= ntohs(udp_hdr->len) from the packet) and walks the L4 buffer that many bytes with no bound against the captured length — so a packet advertising a length beyond the received bytes over-reads. Only receive-path finding
   here (L2 raw-socket mode). Minor secondary: it reads 16-bit words from unaligned offsets (UB; faults on strict-alignment targets).
   Repro: a 53-byte frame whose UDP length field is 0xFFFF.

5. src/stdio.c:152 and :194 (byte_atoi / bitorbyte_atoi) — undefined behavior (low severity)
   Casting an out-of-range double to long/unsigned long (e.g. from -b 1e40P) is a float→int conversion overflow. Garbage value rather than corruption, but UBSan flags it.

Ran clean: inet_pton4/inet_pton6 in compat/inet_pton.c (16M+ execs, nothing).

None are urgent, and most need a deliberately malformed CLI value / baseline file — #4 is the one with a remote angle. Let me know if patches would help and I'll put them together.