Skip to content

Bound CloseError.Error text to the control-frame limit - #1028

Open
AshSgDe29071999 wants to merge 1 commit into
gorilla:mainfrom
AshSgDe29071999:fix/close-error-text-bound
Open

Bound CloseError.Error text to the control-frame limit#1028
AshSgDe29071999 wants to merge 1 commit into
gorilla:mainfrom
AshSgDe29071999:fix/close-error-text-bound

Conversation

@AshSgDe29071999

Copy link
Copy Markdown

Fixes #1002

CloseError.Error appended Text with no length cap. A huge Text (corrupt state or a caller-built value) could OOM while formatting err for a logger.

Truncate to maxControlFramePayloadSize (125), the WebSocket maximum for close-frame payloads. The connection already enforces that limit when parsing close frames.

Error() appended Text without a length cap. A CloseError with a huge
Text (corrupt state or a caller-built value) could OOM while formatting
the error. Truncate to maxControlFramePayloadSize, the protocol maximum
for close-frame payloads.

See gorilla#1002
@jack-flippen

Copy link
Copy Markdown

If the WebSocket package itself can create a CloseError with len(Text) > 125, then that should be fixed.

There’s no reason for an application to construct a CloseError directly. If it does, the application should be responsible for the consequences of setting CloseError.Text to a huge string.

If the Gorilla maintainers nevertheless consider the package responsible for protecting applications from this kind of misuse, then the text should be truncated at a valid UTF-8 boundary.

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] runtime: out of memory: cannot allocate 187650799566848-byte block (1389953024 in use) fatal error: out of memory

2 participants