fix: hardening#49
Conversation
|
Warning Review limit reached
More reviews will be available in 53 minutes and 17 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughAdds a BER REAL zero-significand guard, introduces a dedicated S101 oversized-frame error and size limits in the codec, and updates socket/client paths and tests to drop connections on oversized input while preserving normal decoding. ChangesBER REAL zero-significand guard
S101 oversized-input handling
Sequence Diagram(s)sequenceDiagram
participant Peer
participant S101Socket
participant S101Client
participant S101Codec
alt S101Socket.connect data path
Peer->>S101Socket: data event
S101Socket->>S101Codec: dataIn(data)
S101Codec-->>S101Socket: throw S101OversizedFrameError
S101Socket->>S101Socket: destroy()
else S101Client.connect data path
Peer->>S101Client: data event
S101Client->>S101Codec: dataIn(data)
S101Codec-->>S101Client: throw S101OversizedFrameError
S101Client->>S101Client: handleClose()
end
Review effort🎯 3 (Moderate) | ⏱️ ~30 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
src/S101/__tests__/S101Codec.spec.ts (1)
42-60: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd a regression test for oversized first multi-packet fragment.
Current coverage only overflows during continuation frames. Add a case where
FLAG_FIRST_MULTI_PACKETalone exceeds the cap and is rejected/reset immediately.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/S101/__tests__/S101Codec.spec.ts` around lines 42 - 60, Add a regression case in S101Codec.spec.ts for the oversized first fragment path: the current test in S101Codec.handleEmberFrame only covers overflow during continuation frames, so add a scenario where makeEmberFrame with FLAG_FIRST_MULTI_PACKET and a payload that already exceeds the reassembly cap is rejected immediately. Verify the oversized error is thrown and that the codec state is reset afterward by checking multiPacketBuffer and isMultiPacket on S101Codec.src/Ember/Socket/__tests__/S101Socket.spec.ts (1)
19-35: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winStrengthen oversized test with state assertions.
Please also assert
disconnectedemission andstatus === ConnectionStatus.Disconnectedafter the destroy path, so state regressions are caught.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/Ember/Socket/__tests__/S101Socket.spec.ts` around lines 19 - 35, The oversized-frame test in S101Socket.spec should also verify the socket’s state transition after the destroy path. Extend the existing test around S101Socket and FakeSocket to assert that the disconnected event is emitted and that the S101Socket status becomes ConnectionStatus.Disconnected once the peer is destroyed, alongside the current destroyed/error checks.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/Ember/Socket/S101Socket.ts`:
- Around line 78-81: The oversized-frame drop path in S101Socket can leave the
instance marked as Connected after this.socket?.destroy() triggers the close
flow. Update the oversized error handling in S101Socket and the related
close-state logic so an intentional destroy from S101OversizedFrameError does
not reset status back to ConnectionStatus.Connected; instead, ensure the socket
state is set to a disconnected/closed state consistently in the close handler or
before destroying the socket.
In `@src/S101/S101Codec.ts`:
- Around line 257-263: The multi-packet size guard in S101Codec only runs after
continuation fragments, so an oversized first fragment can still be buffered
past MAX_MULTI_PACKET_SIZE. Update the multi-packet handling in S101Codec so the
size check is applied when the first fragment is written as well as in the
continuation path, reusing the existing resetMultiPacketBuffer and
S101OversizedFrameError flow to drop the message as soon as the accumulated
buffer exceeds the limit.
---
Nitpick comments:
In `@src/Ember/Socket/__tests__/S101Socket.spec.ts`:
- Around line 19-35: The oversized-frame test in S101Socket.spec should also
verify the socket’s state transition after the destroy path. Extend the existing
test around S101Socket and FakeSocket to assert that the disconnected event is
emitted and that the S101Socket status becomes ConnectionStatus.Disconnected
once the peer is destroyed, alongside the current destroyed/error checks.
In `@src/S101/__tests__/S101Codec.spec.ts`:
- Around line 42-60: Add a regression case in S101Codec.spec.ts for the
oversized first fragment path: the current test in S101Codec.handleEmberFrame
only covers overflow during continuation frames, so add a scenario where
makeEmberFrame with FLAG_FIRST_MULTI_PACKET and a payload that already exceeds
the reassembly cap is rejected immediately. Verify the oversized error is thrown
and that the codec state is reset afterward by checking multiPacketBuffer and
isMultiPacket on S101Codec.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 54e1fce3-1d92-43b6-ad5d-09807f6b3298
📒 Files selected for processing (8)
src/Ber/Reader.tssrc/Ber/__tests__/reader.spec.tssrc/Ember/Socket/S101Client.tssrc/Ember/Socket/S101Socket.tssrc/Ember/Socket/__tests__/S101Socket.spec.tssrc/Errors.tssrc/S101/S101Codec.tssrc/S101/__tests__/S101Codec.spec.ts
1 participant
About the Contributor
This pull request is posted on behalf of Bitfocus Companion
Type of Contribution
This is a: Bug fix
Current Behavior
Some potential DOS vulnerabilities have been identified
New Behavior
Testing Instructions
Other Information
Status