Closed 5225225 closed 2 years ago
While slightly different input, it seems this is also fixed with https://github.com/hyperium/h2/commit/dbaa3a42856d23c6bdebb6125c2205d965532178 (release planned for today). When I patch in h2
from git, it no longer panics.
Hm, I can still reproduce it, even when patching h2 from git.
My cargo.toml for the target server looks like
[package]
name = "scratch0dtkkKHQJ"
version = "0.1.0"
edition = "2021"
[patch.crates-io]
h2 = { git = "https://github.com/hyperium/h2/" }
[dependencies]
rocket = "0.5.0-rc.1"
crash.zip is the full file in a zip. I'm not doing anything special to send it over, just netcat localhost 8000 < crash
. Github says dbaa3a4 is merged to master, so h2 = { git = ... }
should pick up that fix if it exists, right? That or I'm getting the format for patch wrong.
There's now a new version of cargo, so removing the "patch" and just trying cargo update -p h2
and retrying should work.
I tried out your your steps and the newer h2 worked for me, at least.
Huh.
I ran a cargo update
and removed the patch and the test crate is now using 0.3.8 of h2, but I can still reproduce it.
thread 'rocket-worker-thread' panicked at 'assertion failed: !id.is_zero()', /home/jess/.cargo/registry/src/github.com-1ecc6299db9ec823/h2-0.3.8/src/proto/peer.rs:54:9
Maybe it's the way rocket's running it?
It's got h2-0.3.8 in the path so I'm fairly sure it's running the latest code.
Can you post how you're running it?
I am running on a nightly, but even running on stable works fine.
Here's what I did:
I took the hyper repo, I ran in one terminal:
RUST_LOG=hyper,h2 cargo run --features full --example hello
And then in a separate terminal, I ran:
echo "DVBSSSAqIEhUVFAvMi4wDQoNClNNDQoNCgAAKgEAAAAAAKa8jry8vLy8vLy8vLy8vLy8vLy8vLy8vLysvLy8pqampqampqaupqampqampqamJqampqamplpZWVl5WVlXpqampqaAgICAgICAgICAgICAgICA" | base64 -d | nc localhost 3000
This produced the panic message you reported, and then after running cargo update
to have the newest h2
, it no longer panicked. The logs now show that an error was detected, and the connection state transitions to closing, and then closes.
Yeah, I can reproduce that command working fine now, but
echo "DVBSSSAqIEhUVFAvMi4wDQoNClNNDQoNCgAAKgUAAAAAAAAAAYODg4ODg4ODZoODg4O+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6Dg4Ourq6uCwAAAL6+vr6+" | base64 -d | nc localhost 3000
still fails on the same assert as the original.
Should I close this issue and re-open one for that?
I used rocket (0.5.0-rc.1) as a handy test case for this, but I found the bug when fuzzing hyper, and it seems to be in this repo.
To reproduce, feed the uploaded file into a rocket instance (
base64 -d ... | nc localhost 8000
)I just used the hello world, it likely really doesn't matter.
is a full stack trace