fix(snappy): reject >9-byte uvarint continuation runs (no integer-overflow panic)

[zclawz]

Bug

uvarint() in snappy.zig panics with integer overflow when the input contains 10+ continuation bytes (b >= 0x80).

Reproduction in zeam Hive (test gossip: ignores malformed ssz — 27 zeam_devnet4 cascade failures from this single panic):

thread 64 panic: integer overflow
snappy.zig:73:11 in uvarint     s += 7;
snappy.zig:105:27 in decodedLen const varint = uvarint(src);
snappy.zig:265:33 in decodeWithMax

The simulator publishes 1024 bytes of 0xef on a valid gossip topic. Each 0xef has the high bit set, so uvarint keeps looping. The shift counter s: u6 reaches 63 after 9 iterations, and s += 7 on the 10th iteration overflows the u6, panicking the network thread and crashing the client.

Fix

Reject as malformed (return the corrupt sentinel bytesRead == 0) as soon as the loop sees its 10th continuation byte. A 64-bit varint is at most 10 bytes long, so further bytes can't possibly be valid — and we must bail before the next s += 7.

Also tightened decodedLen()'s corrupt check from <= 0 to == 0. The old check was a no-op for any sentinel: bytesRead is usize and the previous "corrupt" path returned -%i + 1 which wraps to a huge usize, never <= 0.

Edge cases covered (new tests)

• 1024 bytes of 0xef (the actual Hive payload) → Corrupt, no panic
• Exactly 10 continuation bytes, no terminator → corrupt
• 11 continuation bytes followed by a valid terminator → corrupt
• 10th byte with value > 1 (overflows u64) → corrupt (existing rule, still enforced)
• 10th byte with value == 1 (max u64 = 0xffff_ffff_ffff_ffff) → 10 bytes consumed, valid
• Empty buffer → bytesRead == 0, no read
• decode and decodeWithMax on the 1024×0xef payload → error.Corrupt

Verification

$ zig build test --summary all
Build Summary: 3/3 steps succeeded; 9/9 tests passed

The regression test decode rejects garbage with long continuation run reproduces the exact zeam Hive scenario.

Companion change

A follow-up PR on blockblaz/zeam will bump this dep so the live Hive failure clears. cc @ch4r10t33r

[zclawz]

Thanks for the careful review. Pushed a01e503 addressing 1, 2, 3, 4, 5, 6, 7, 9, 10. Filing 8 as a follow-up issue.

1. Restructured to for (buf[0..@min(buf.len, 10)], 0..) so the 10-byte budget lives in the loop bound. Loop can't reach i == 10 by construction; s += 7 can't push s:u6 past 63 by construction. Both internal guards are now i == 9 (the in-loop continuation-bit-still-set case stays as a guard because we still need to bail before the next iteration's s += 7 runs).

2. Added a doc block on Varint explicitly calling out that bytesRead == 0 is overloaded across truncated and malformed inputs, that the Go reference distinguishes via negative byte count, and what to do if uvarint is ever made pub (switch to ?Varint or isize).

3. Comment rewritten: "10th byte (i == 9) with continuation bit still set: varint exceeds the 64-bit budget. Bail before the next s += 7 would overflow the u6 shift counter."

4. Reverted. Original <= 0 is preserved; for usize it's identical to == 0 and the previous "tightened" framing was misleading.

5. All early-return Varint{} literals now multi-line, matching the existing style.

6. Every malformed sub-case now asserts both bytesRead == 0 and value == 0.

7. "malformed gossip payload" line is gone from the library; the regression detail stays in the test comment where it belongs.

8. Out of scope, will file a follow-up issue: a 1k-iteration random-bytes fuzz against decode/decodeWithMax would catch sibling panics in runDecode and other malformed-input crashes. Linked here once filed.

9. Added: [0xff] * 9 exactly. This is the truncated-input codepath that falls through the post-loop return, which is distinct from the i == 9 guard. Comment in the test calls out the distinction.

10. Added: [0x80, 0x00] non-canonical encoding of zero. Pins current behaviour (the varint format doesn't require minimal encoding) so any future tightening is a deliberate breaking change rather than a silent drift.

Final diff: +88 / -42 in snappy.zig. zig build test 9/9 green. The 1024×0xef repro still returns error.Corrupt instead of panicking.

[zclawz]

Re: point 8 (fuzz follow-up) — I tried to file it as an issue here but issues are disabled on this repo. Sketch below for the next time we touch this file or open a tracker repo:

test "fuzz: decode never panics on random input" {
    const allocator = testing.allocator;
    var prng = std.Random.DefaultPrng.init(0xDEAD_BEEF_CAFE_F00D);
    const random = prng.random();

    var buf: [4096]u8 = undefined;
    var i: usize = 0;
    while (i < 1024) : (i += 1) {
        const len = random.intRangeAtMost(usize, 0, buf.len);
        random.bytes(buf[0..len]);
        if (decode(allocator, buf[0..len])) |out| { allocator.free(out); } else |_| {}
        if (decodeWithMax(allocator, buf[0..len], 16 * 1024 * 1024)) |out| { allocator.free(out); } else |_| {}
    }
}

Goal: catch sibling panics in runDecode (tag-literal length boundaries, tagCopy* offset casts, the dst[d - offset ..] slicing, etc.) the same way #9 caught the one in uvarint. Deterministic seed so CI failures reproduce locally; both decode and decodeWithMax exercised so we cover the early-bail path and the full-decode path. Out of scope for #9; happy to open a separate PR for it after this one merges.