[PR] fix: bound inbound Artery TCP frame length at framing [pekko]

["pjfanning (via GitHub)" <gi...@apache.org>]

pjfanning opened a new pull request, #3492:
URL: https://github.com/apache/pekko/pull/3492

   ### Motivation
   `TcpFraming` read the 4-byte frame length from the wire and passed it straight to `reader.take` / `ByteBuffer` allocation with no bound (`ReadFrame.parse`). A peer — unauthenticated on the default `tcp` transport — could declare an oversized (up to ~2 GiB) or negative frame length and drive a large allocation.
   
   This matters more than a single connection because the decoder and deserializer stages downstream of the inbound `MergeHub` are **shared by every inbound connection**. A fatal `OutOfMemoryError` there fails the shared inbound stream, and `ArteryTransport.attachInboundStreamRestart` terminates the whole `ActorSystem` after `inbound-max-restarts` (default 5) failures within `inbound-restart-timeout` (default 5 s) — so one malformed connection can escalate to node loss.
   
   ### Modification
   - Thread the already-configured `maximum-frame-size` and `maximum-large-frame-size` into `TcpFraming`.
   - A connection carries a single stream for its lifetime, so `ReadStreamId` selects the applicable bound (the large-message stream keeps its larger limit) and `ReadFrame` rejects a frame length that is negative or over that bound **before any data is buffered**.
   - Rejection is a `FramingException`, which tears down only that connection — the correct per-connection outcome, and never a fatal error on the shared stream.
   
   New constructor params default to `Int.MaxValue`, so the change is source- and binary-compatible; `TcpFraming` is `@InternalApi` regardless.
   
   ### Result
   A malformed or oversized frame is rejected per-connection instead of allocating without limit and risking a fatal error that escalates to `ActorSystem` termination. Legitimate frames up to the configured maxima are unaffected.
   
   ### Tests
   - `sbt "remote/testOnly org.apache.pekko.remote.artery.tcp.TcpFramingSpec"` — 14 passed, including new oversized, negative-length and at-the-limit frame cases
   - `sbt "remote/testOnly org.apache.pekko.remote.artery.LargeMessagesStreamSpec"` — 4 passed (legitimate large frames still delivered end-to-end)
   - `sbt "remote/mimaReportBinaryIssues"` — no issues
   
   ### References
   None - found while reviewing the draft threat model in #3478
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@pekko.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@pekko.apache.org
For additional commands, e-mail: notifications-help@pekko.apache.org

Re: [PR] fix: bound inbound Artery TCP frame length at framing [pekko]

["pjfanning (via GitHub)" <gi...@apache.org>]

pjfanning merged PR #3492:
URL: https://github.com/apache/pekko/pull/3492


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@pekko.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@pekko.apache.org
For additional commands, e-mail: notifications-help@pekko.apache.org