You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The get and put family of functions on MessageBuffer use unsafe memory accesses and are missing bounds checks. They can thus can read and write out of bounds.
E.g. in the following example getInt either causes a segfault or returns an undefined value:
val unpacker =MessagePack.newDefaultUnpacker(ByteArray(0))
val buffer = unpacker.readPayloadAsReference(0)
val value = buffer.getInt(9000000)
println("Value: $value")
Since this unsafety is exposed publicly and is not documented, it can be quite dangerous.
If the ability to skip the bounds check is an intended feature, then I'd suggest to name the methods accordingly (e.g. giving them an "unsafe" prefix). Having a set of functions that does bounds checking by default probably does not hurt either.
The text was updated successfully, but these errors were encountered:
panicbit
changed the title
MessageBuffer allows unsafe out-of-bounds reads and writes
MessageBuffer allows out-of-bounds reads and writes
Dec 24, 2020
panicbit
changed the title
MessageBuffer allows out-of-bounds reads and writes
MessageBuffer allows unsafe out-of-bounds reads and writes
Dec 27, 2020
@panicbit Thanks for the report. Although this method has been exposed, we have no intention to let normal users who don't have the internal implementation knowledge of msgpack-java to rely on this functionality. As this method is already used in some of our dependencies, renaming this method to readUnsafeXXX cannot be our option. And also, adding boundary checks to MessageBuffer methods might also have non-negligible performance overhead, so let us just fix the documentation as in #546
The
get
andput
family of functions onMessageBuffer
use unsafe memory accesses and are missing bounds checks. They can thus can read and write out of bounds.E.g. in the following example
getInt
either causes a segfault or returns an undefined value:Since this unsafety is exposed publicly and is not documented, it can be quite dangerous.
If the ability to skip the bounds check is an intended feature, then I'd suggest to name the methods accordingly (e.g. giving them an "unsafe" prefix). Having a set of functions that does bounds checking by default probably does not hurt either.
The text was updated successfully, but these errors were encountered: