[
https://issues.apache.org/jira/browse/CASSANDRA-14997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750933#comment-16750933
]
Alex Petrov commented on CASSANDRA-14997:
-----------------------------------------
|[trunk|https://github.com/ifesdjeen/cassandra/tree/CASSANDRA-14997-trunk]|[ci|https://circleci.com/workflow-run/d2e04a88-2c96-4f93-947d-e926659018fa]|
Patch does the following:
* Avoid allocating buffer if/when this can be avoided, use wrapped buffers
Instead
* Do not pass expected decompressed length to JNI decompressor until the bug
is fixed
* reuse Snappy-supplied length
Currently, passing Integer.MAX_VALUE would still tip the node over, but to be
honest I'm not sure if checking for things like free memory is reasonable in
this case and I'm not sure what would be an acceptable alternative here, since
realistically we're guarded corruption by checksumming, so the only scenarios
where this might happen is driver bug or adversarial message construction.
I did also check a few other places where we might cause similar behaviour
(query string encoding, frame length, etc) and it seems that those places are
guarded (e.g. result into protocol error rather than tipping the node over).
> OOM or segmentation fault tipping node over on erroneous uncompressed lengths
> ------------------------------------------------------------------------------
>
> Key: CASSANDRA-14997
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14997
> Project: Cassandra
> Issue Type: Bug
> Reporter: Alex Petrov
> Assignee: Alex Petrov
> Priority: Major
>
> Native protocol handler can tip node over if incorrect uncompressed length is
> set while using compression.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
