Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit maximal size of incoming fragment. #252

Merged
merged 1 commit into from Feb 21, 2019
Merged

Limit maximal size of incoming fragment. #252

merged 1 commit into from Feb 21, 2019

Conversation

tomusdrw
Copy link
Contributor

Since frame size is allowed to be up to 2^64 one can forge a frame that declares extremely large payload size.

In case we haven't received enough data yet:
https://github.com/housleyjk/ws-rs/compare/master...tomusdrw:td-maxframe?expand=1#diff-8c1748e0d20c7a39978ef7656d9f39f4R326

we reset the cursor position and wait for more data in in_buffer.

By default the in_buffer is allowed to grow indefinitely, so the server will go OOM at some point trying to read such a big frame.

PR introduces additional setting max_fragment_size which defines maximal (sane) allowed frame payload size.

@@ -158,6 +158,9 @@ pub struct Settings {
/// The maximum length of outgoing frames. Messages longer than this will be fragmented.
/// Default: 65,535
pub fragment_size: usize,
/// The maximum length of acceptable incoming frames. Messages longer than this will be rejected.
/// Default: unlimited
pub max_fragment_size: usize,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the implementation you are using u64 and here usize? Why not use u64 everywhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

u64 is required by the Cursor API. I prefer usize in the settings for two reasons:

  1. Consistency with fragment_size
  2. It is restricted by the available memory anyway, so I think usize describes that better. In the worst case we are going to be upcasting.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay :)

@tomusdrw
Copy link
Contributor Author

@housleyjk Any chance to get a review on this one?

@gnunicorn
Copy link

I think @Eijebong might be the person you want to talk to regarding that, @tomusdrw :) .

@tomusdrw
Copy link
Contributor Author

fwiw we've pushed parity-ws (https://github.com/paritytech/ws-rs) fork of this repo to crates.io to move forward, but we're really willing to rely on this crate directly when new version is released.

@Eijebong
Copy link
Collaborator

Sorry, been quite busy with other stuff recently. Thanks for the PR.

@Eijebong Eijebong merged commit 138b26a into housleyjk:master Feb 21, 2019
@tomusdrw tomusdrw deleted the td-maxframe branch February 21, 2019 12:56
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.

None yet

4 participants