[alosafuzz]

Summary

The typed-data deserializers read an element/field count off the wire and then allocate
(new[] / reserve) from it before reading any element data, without bounding the declared
count against the bytes remaining in the message. A small message that declares a very large
array/field count therefore drives a correspondingly large allocation.

This PR clamps each declared count to buf.size() before allocating. Since every encoded element
occupies at least one byte on the wire, a valid count can never exceed the bytes remaining, so this
is a no-op for well-formed messages.

Sites bounded:

• src/pvaproto.h — array decode shared_array<E> arr(slen.size)
• src/dataencode.cpp — struct child-count reserve(nfld.size), and the StructA / UnionA /
  AnyA array decoders shared_array<Value> arr(alen.size)

Context / reachability

Reached via from_wire_type_value, which ServerConn::handle_CONNECTION_VALIDATION() calls on the
client-supplied auth value during the initial handshake (before authentication). The message body is
bounded by the header len, but the declared count inside the body is independent of len.

Measured impact (low — this is hardening, not a reported DoS)

On a 64-bit host with memory overcommit (a typical IOC) the oversized new[] is a lazy reservation
that never commits: a ~9-byte input requesting ~8 GB completes in ~17 ms at ~33 MB peak RSS, because
the element-read loop only touches the bytes the message actually carries. On a host with overcommit
disabled or a tight ulimit the allocation instead throws std::bad_alloc. I am not claiming a
practical denial of service — this is an unbounded-allocation-from-declared-count pattern (CWE-770)
that is cheap to bound. (One thing I did not verify: on a 32-bit target count * sizeof(E) could
overflow size_t and under-allocate; worth a glance.)

How it was found

Coverage-guided fuzzing (libFuzzer + ASan/UBSan) of pvxs::impl::from_wire_type_value in isolation.
After adding these bounds, a re-fuzz of the full decode path (dataencode / data / bitmask / type /
sharedarray) over tens of millions of executions found no memory-safety issues.

Tested against current master (4311a85). Happy to adjust the approach (e.g. reject vs. clamp) to your
preference.