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
Surfaced from Informal Systems IBC Audit of cosmos-sdk hash 82f15f3.
Summary of Bug
Malformed txs can cause the TxDecoder to panic. This doesn't seem to crash the node, since the panics are handled, but the TxDecoder should probably be more robust anyways.
Note that when you do run it against a node (eg. simd), you can't see the stack trace, the Response.Log is just "panic". Not sure if the stack trace is being purposefully or accidentally cut off here, but might be valuable to preserve it somewhere? Eg. even if its just in the process logs.
…n error
Given that protowire.ConsumeFieldValue returns -1 when it encounters an
error, perform a check for n < 0 and return the respectively obtained
error with context about the details.
Fixes an issue identified from a go-fuzz session, thanks to Ethan
Buchman and the IBC auditors from Informal Systems et al.
Fixes#7739.
…n an error (#7770)
* unknownproto: check result from protowire.ConsumeFieldValue and return error
Given that protowire.ConsumeFieldValue returns -1 when it encounters an
error, perform a check for n < 0 and return the respectively obtained
error with context about the details.
Fixes an issue identified from a go-fuzz session, thanks to Ethan
Buchman and the IBC auditors from Informal Systems et al.
Fixes#7739.
* Address AlexanderBez's suggestions
* Use require in tests
* Add issue #7846 to TODO
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Surfaced from Informal Systems IBC Audit of cosmos-sdk hash 82f15f3.
Summary of Bug
Malformed txs can cause the TxDecoder to panic. This doesn't seem to crash the node, since the panics are handled, but the TxDecoder should probably be more robust anyways.
Note that when you do run it against a node (eg. simd), you can't see the stack trace, the Response.Log is just "panic". Not sure if the stack trace is being purposefully or accidentally cut off here, but might be valuable to preserve it somewhere? Eg. even if its just in the process logs.
Version
82f15f3 (recent)
Steps to Reproduce
The bug was found by starting to play with go-fuzz. The following self-contained go test demonstrates the panic:
This results in
For Admin Use
The text was updated successfully, but these errors were encountered: