[BUG] Reject CRcvBuffer::dropMessage range past buffer end

[mszatmary-netflix]

dropMessage early-returns when offset_b < 0 (the entire range is before the buffer start), but does not symmetrically guard against offset_a >= m_szSize (the entire range is past the buffer end). In that case start_off = offset_a is unbounded; incPos() wraps modulo m_szSize and the loop walks legitimate buffer entries, marking them EntryState_Drop -- corrupting receiver state from a single malformed call.

Add a symmetric early return for offset_a >= m_szSize.

Add CRcvBufferReadMsg.PacketDropLoPastBufferEnd covering the new guard: insert two packets, request a drop whose lo is well past the buffer end, assert no packets were dropped and the buffered packets are still readable.

[ethouris]

If you add here also the check if offset_a <= offset_b, you can dismiss checking entry arguments for UMSG_DROPREQ handler.

[mszatmary-netflix]

If you add here also the check if offset_a <= offset_b, you can dismiss checking entry arguments for UMSG_DROPREQ handler.

That is true. But generally a function should guard its own inputs rather than requiring each caller to sanitize first

[ethouris]

The problem is, you can't do the right checks on the sequence numbers only, without reflecting them through the base sequence numbers in these structures - and unfortunately the receiver buffer and the receiver loss structures are separate.