fix(cell)!: refuse a negative serial type instead of wrapping it into a length

[h4x0r]

A negative serial type wraps into a near-usize::MAX length and overflows the range arithmetic in decode_value.

Found by fuzzing ios-backup-core, whose Manifest.db path feeds this decoder attacker-controlled SQLite bytes.

The defect

n => {
    // odd, >= 13: text
    let len = ((n - 13) / 2) as usize;
    let bytes = buf.get(off..off + len).ok_or(Error::TruncatedCell)?;

A serial type is a varint, so a damaged record decodes one as a negative i64. Every arm above 11 is written for the positive cases, so negatives fall through to this catch-all:

serial	((n - 13) / 2) as usize
-1	18446744073709551609
-3	18446744073709551608
i64::MIN + 1	underflows at the subtraction

buf.get(range) reads as though the bounds check covers this. It does not — the range is constructed before get is handed it.

• with overflow checks (fuzz/debug/test): panic, in a crate documented as never panicking on malformed input
• in release: wraps to a small number, get succeeds, and the caller receives bytes that are not the value

The release behaviour is the worse one, and it is the one that ships.

The fix

• text arm guarded n if n >= 13, so the subtraction cannot underflow by construction
• negatives get an explicit arm returning Error::MalformedSerialType { serial, offset }, carrying the offending value and where it was read — folding them into TruncatedCell would send a reader hunting for a truncation that is not there
• a span() helper checked_adds before building any evidence-derived range; read_be_u64 moves onto it too

span() is the part that generalises. The same shape was already known here — line 4887 uses saturating_add for exactly this — and it never reached its siblings.

The remaining off + 2 / off + 4 / off + frame_stride sites are deliberately untouched: each addend is a small constant or bounded by the enclosing slice walk, so none can overflow, and churning them would bury the two that mattered.

Breaking

Error gains a variant and becomes #[non_exhaustive]. Both are breaking, so they land together and spend the break once. Being a 0.x crate, consumers pinned at "0.11" are not moved involuntarily.

There is no Display impl to update — Error derives only Debug today. That's a real gap, worth its own change.

Verification

• RED then GREEN as separate commits (6616da2, 14bb9b5). RED failed at core/src/lib.rs:4700 with attempt to subtract with overflow — the intended reason, not a compile error
• a companion test pins serial 12/13 decoding to empty blob/text, so the fix cannot buy safety by rejecting the smallest legal values
• 552 tests across 71 targets pass (--no-fail-fast), no regression
• the 4.1 KB minimized input that crashed ios-backup-core now executes cleanly through a patched build
• a fresh 2,214,953-run seeded session added 1,947 corpus units and produced no artifact
• fmt / clippy -D warnings / deny / vet all clean

🤖 Generated with Claude Code