Closed pawanjay176 closed 4 years ago
Definitely looks like a bug. Also looks like the bug is here too:
Either checked subtraction or just adding an explicit if len < 4 { return error(...) }
sounds great to me! Thanks for catching this!
Sure, no worries.
I'm trying to think what Error
variant would be appropriate for this case. The closest fit seems to be UnsupportedChunkLength
https://github.com/BurntSushi/rust-snappy/blob/1951d5d267c2c363c202096f43a026ec0d91f0fc/src/error.rs#L156-L165
but the docs for this variant says trying to read a chunk with length greater than that supported
. which isn't right.
Maybe this requires a new error variant along the lines of InvalidChunkLength
?
Ug. I meant to make the enum non-exhaustive when I did the 1.0 release. So that means adding a new variant is a breaking change.
UnsupportedChunkLength
looks fine. The name is right anyway. I'd just tweak the description to be a bit more generic, i.e., "a chunk with an unexpected or incorrect length."
Ug. I meant to make the enum non-exhaustive when I did the 1.0 release. So that means adding a new variant is a breaking change.
Sorry, didn't think of this.
I'd just tweak the description to be a bit more generic, i.e., "a chunk with an unexpected or incorrect length."
This sounds great. Will do this.
Got the same panic today:
use snap::read;
use std::io::Read;
fn main() {
let data: &[u8] = &[0x10, 0x10, 0x0, 0x0];
let mut buf = vec![];
read::FrameDecoder::new(data).read_to_end(&mut buf).unwrap();
}
# ./target/release/testing
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom
{ kind: Other, error: StreamHeader { byte: 16 } }', src/libcore/result.rs:11$
8:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace$
found it with the help of https://github.com/rust-fuzz/cargo-fuzz
@flipchan That's not the same panic. And it's not even clear that it's a bug. You're calling unwrap
on a fallible operation, which will panic if an error occurs. The only way your code sample is a bug is if the input is a valid Snappy compressed frame. (It doesn't look like it is.)
Encountered a panic
thread 'main' panicked at 'attempt to subtract with overflow',
while decoding malformed input bytes.The panic occurred here https://github.com/BurntSushi/rust-snappy/blob/1951d5d267c2c363c202096f43a026ec0d91f0fc/src/read.rs#L191
The malformed input after providing the correct stream identifier chunk has 4 zero bytes which leads to
len
becoming 0 and hence panics when we try to do unsafe subtraction in line 191.The stack trace:
I think we can fix this by doing checked subtraction and returning an error if there's an underflow. Will be happy to raise a PR if you can confirm it's an issue :)