fix: F-2026-18804 | [Dual Defense] EVM ABI readDynamicBytes Uint64 Overflow Panics Can Kill puniversald

[Aman035]

F-2026-18804 ABI decoder overflow panics

Issue

• readDynamicBytes bounded with additive uint64 arithmetic. Both inputs come from log data an RPC supplies, so both can be chosen to wrap.
• absOff+32 wraps small and passes the guard → data[absOff:absOff+32] panics.
• dataStart+byteLen wraps below dataStart → the length guard fails open → data[dataStart:dataEnd] panics.
• Nothing on the listener path recovers, so either panic ends puniversald — every chain plus TSS in that process.

Reproduced both before fixing: slice bounds out of range [18446744073709551599:15] and [32:31].

Approach taken

• Bounds are now checked by subtracting from the buffer length instead of adding to the offset, so no intermediate can wrap: absOff > n || n-absOff < 32, then n-dataStart < byteLen.
• ParseEvent recovers, logs the panic with tx hash and log index, and returns nil so the log is skipped like any other undecodable one. The decode logic is unchanged — the recover is a thin wrapper around it.

The recover is deliberately at the log boundary rather than the poll loop: one malformed log is skipped, everything else in the batch still processes, and a genuine bug elsewhere still surfaces rather than being swallowed silently.

Scope

Swept the other decoders for the same class — the overflow is unique to readDynamicBytes, every other computed bound is already checked before slicing.

Tests

• Offsets at MaxUint64 and the four values that wrap +32 onto a small number are all rejected.
• A length word of MaxUint64 is rejected rather than wrapping the end below the start.
• Well-formed input, zero length, and a length just past the buffer all still behave.
• End to end: a log whose payload offset overflows is skipped without panicking.
• Mutation checked: restoring the additive bounds panics the offset test; removing the recover fails the end-to-end test.