Skip to content

TL/MLX5: validate mcast packet fields#1302

Open
janjust wants to merge 1 commit intoopenucx:masterfrom
janjust:master-mlx5-mcast-validate-imm-data
Open

TL/MLX5: validate mcast packet fields#1302
janjust wants to merge 1 commit intoopenucx:masterfrom
janjust:master-mlx5-mcast-validate-imm-data

Conversation

@janjust
Copy link
Copy Markdown
Collaborator

@janjust janjust commented Apr 28, 2026

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.

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.

Signed-off-by: Tomislav Janjusic <tomislavj@nvidia.com>
@janjust janjust requested a review from MamziB April 28, 2026 22:55
@janjust
Copy link
Copy Markdown
Collaborator Author

janjust commented Apr 29, 2026

/build

@MamziB
Copy link
Copy Markdown
Collaborator

MamziB commented Apr 29, 2026

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants