TLVu8sDrain's fast path classifies records by bit 0x20 alone, so huge-type bytes ('!'..':' = 0x21..0x3A, produced by the module's own TLVu8sEndHuge) parse as SHORT records — wrong boundary, stream desync. Plus signed-shift UB and leftover unaligned casts on wire data. Found 2026-07-07; the bit overlap is verified against TLV.h/TLV.c. Complements PTR-001 (TLV.c:169-238 sites already fixed there, pending review).
TLV.h:34-45 TLVu8sDrain — if ($len < 2 || !(**from & TLVaA)) falls
through to the short-record parse for ANY byte with bit 0x20: huge types 0x21-0x3A take len = low byte of the u64 length; garbage bytes (0x20, 0xFF) that TLVprobe rejects (TLVBADREC) are accepted. Feed/Drain asymmetry: the module emits records its primary drain cannot parse.
TLV.c:17-18 TLVprobe — $at(data,4) << 24 on promoted int: lengthbyte ≥ 0x80 is signed-overflow UB on untrusted wire data (bound check at :31 hides it in practice). Cast to u64 before shifting.
TLV.c:23 *(u64*)(*data+1)
read in the huge branch; TLV.h:64-67 (u32p)*hdr write in TLVu8bOuto (a header!); TLV.c:65/78 deprecated TLVOpen/TLVClose pair.
size_t without a u32max guard in
TLVu8bOuto, _TLVu8sFeed (TLV.c:52), TLVEndAny, TLVu8sEnd — TLVu8bInto shows the intended TLVTOOLONG guard.
desync today, round-trip after the fix. Fuzz drain with high-bit bytes.
TLVprobe's type-range logic), u64-cast shifts,memcpy-backed field access, u32max guards.
with existing valid streams; only invalid/huge handling changes.