SBN_ProcessSubsFromPeer: cap SubCnt at SBN_MAX_SUBS_PER_PEER

[nurdymuny]

Summary

Cap SubCnt from a peer-supplied subscription message at SBN_MAX_SUBS_PER_PEER before entering the dispatch loop. Closes #92.

Why

SBN_ProcessSubsFromPeer reads SubCnt (uint16, peer-controlled) and loops up to SubCnt times calling Unpack_Data + ProcessSubFromPeer. The inner function correctly rejects writes past SBN_MAX_SUBS_PER_PEER (so no memory corruption), but the outer loop still spins up to 65535 iterations per malformed packet. A compromised or glitching peer can pin a receiving CPU and flood the EVS log with a single packet, repeated.

Diff

 fsw/src/sbn_subs.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

if (SubCnt > SBN_MAX_SUBS_PER_PEER)
{
    EVSSendErr(SBN_PROTO_EID,
               "peer CpuID %d sent SubCnt=%u, exceeds SBN_MAX_SUBS_PER_PEER=%u",
               Peer->ProcessorID, (unsigned)SubCnt,
               (unsigned)SBN_MAX_SUBS_PER_PEER);
    return SBN_ERROR;
}

Mirrors the existing version-hash mismatch early-return one block up in the same function.

Tests

• Manual: hand-built a subscription message with SubCnt=0x4000 (>SBN_MAX_SUBS_PER_PEER=256 by default), confirmed the function returns SBN_ERROR immediately with a single log line instead of spinning 16k iterations.
• Existing well-formed subscription messages still dispatch normally.

Linked

Closes #92.