-
Notifications
You must be signed in to change notification settings - Fork 380
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't crash when the packet length is zero #389
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you for working on this. I don't see much value in fuzzing the private API. Can you demonstrate that this crash can be trigged via a public API?
Not an API, but a client panics when it connects to a broken server like the following one: func TestBrokenServer(t *testing.T) {
cr, sw := io.Pipe() // client reads, server writes
sr, cw := io.Pipe() // server reads, client writes
// Broken server that doesn't speak proper SFTP.
go func() {
go io.Copy(ioutil.Discard, sr)
sw.Write([]byte{0, 0, 0, 0})
sw.Close()
}()
NewClientPipe(cr, cw)
} |
d2a7d72
to
d95066f
Compare
I can change the fuzz test to do something similar. It would be more expensive to run, obviously. |
Can you write that as a failing test case? |
Remember that new client pipe doesn't actually need an io.pipe, that should make the test simpler, and simpler to write a fuzzer |
d95066f
to
b10556f
Compare
New test and fuzzer now calls NewClientPipe. |
The test failure is the same as one master (fixed in #387). |
d21b507
to
92cc5dc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for working on this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for working on this
I don't see the utility of testing recvPacket for short packets. I would like to see a test against the external API exposed by NewClientPipe. If recvPacket crashes because the input is smaller than expected then this is the fault of its caller. It should be fixed at that point.
230835f
to
96cf5ed
Compare
Done, and also added a test that crashes the server on current master. |
96cf5ed
to
ddfcb01
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you. I'll leave this for the other maintainers.
Probably fine from me as well, but I’d like to get #387 merged first. Then a rebase would be required here. |
ddfcb01
to
5d0f048
Compare
5d0f048
to
816cb21
Compare
Rebased on #387. |
816cb21
to
e67e3df
Compare
e67e3df
to
80d91be
Compare
80d91be
to
72b0592
Compare
72b0592
to
cb15563
Compare
A packet with an invalid length causes a panic in recvPacket. Patch includes the fuzz test that found this out in a few seconds.