TL/MLX5: validate mcast packet fields

[janjust]

Reject multicast packets with invalid decoded source rank, offset, or length before using wire-supplied fields for receive tracking or destination calculation.

Make packet recycling aware of pending-queue entries so dropped packets do not leave zero-copy receive tracking stale.

[janjust]

/build

[MamziB]

@janjust Thanks for the PR. However, what exact bug is this fixing? If there is a real case where we receive a bad/stale packet or hit an out-of-bounds access, please describe how to reproduce it and what should happen after the packet is dropped.

Right now this looks like extra defensive checks in a very sensitive receive path. Since the code silently drops packets and still returns UCC_OK, I’m worried it could change completion behavior or hang if the reliability path does not recover that packet.

[MamziB]

Hi @janjust
I thought about it more. I still don’t think this PR is the right fix, but I also don’t think we should reject the security finding entirely. So the safer position is: we accept that validation is needed, but we need a narrower fix that keeps completion semantics instead of silently dropping packets and returning UCC_OK