Bound protocol message sizes before allocating#108
Open
plaidfinch wants to merge 1 commit into
Open
Conversation
recv_msg allocated the full message buffer from the peer-controlled length prefix before reading any of the body, so a TLS-authenticated (but not yet attested) peer could demand a 4 GiB zeroed allocation with a 4-byte prefix, and hold it by leaving the connection open — repeatable across connections for memory exhaustion. Authenticated-but-unattested is exactly the adversary class the attestation layer exists to screen out, so the framing layer must not trust it with allocation sizes. Bound messages at a named MAX_MSG_SIZE (1 MiB), with compile-time asserts that the bound admits the largest legitimate messages (the hubpacked measurement log and attestation). Oversized lengths are rejected as a new Error::MessageTooLarge before any allocation. No interoperability change: every legitimate protocol message is far below the bound.
This was referenced Jul 17, 2026
plaidfinch
marked this pull request as ready for review
July 17, 2026 20:46
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CAVEAT LECTOR: This PR was generated by Claude Fable 5.
Problem
recv_msgallocates the full message buffer from the peer-controlled length prefix before reading any of the body, so a TLS-authenticated (but not yet attested) peer can demand a 4 GiB zeroed allocation with a 4-byte prefix, and hold it by leaving the connection open, repeatably across connections, for memory exhaustion.I posit that authenticated-but-unattested is the adversary class the attestation layer exists to screen out (e.g. a compromised sled with legitimate certs), so the framing layer must not trust it with allocation sizes.
Fix
Bound messages at a named
MAX_MSG_SIZE(1 MiB) checked before allocation, rejected as a newError::MessageTooLarge { len, max }. Compile-time asserts prove the bound admits the largest legitimate messages (the hubpacked measurementLogandAttestation); cert chains and nonces are far smaller. No interoperability change.Testing
New regression test
oversized_message_rejected: an authenticated client sends au32::MAXlength prefix with no body; the server must reject on the prefix alone.Verified on illumos:
cargo test7/7, CI-style clippy clean.Relationships
Independent of #107 and #109; the three can land in any order.