Skip to content
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

Bug in tcp option parsing? #74

Closed
phil-opp opened this issue Nov 8, 2017 · 2 comments
Closed

Bug in tcp option parsing? #74

phil-opp opened this issue Nov 8, 2017 · 2 comments

Comments

@phil-opp
Copy link
Contributor

phil-opp commented Nov 8, 2017

I think there is a bug in this line in wire/tcp.rs:

length = *buffer.get(1).ok_or(Error::Truncated)? as usize;
let data = buffer.get(2..length).ok_or(Error::Truncated)?;

I think it should be buffer.get(2..(2+length)) instead, because otherwise we try to take the range 2..1 for an option with length 1.

@whitequark
Copy link
Contributor

Nope: https://play.rust-lang.org/?gist=bb7d8c35c1d97d35c88a8919498866e3&version=stable

See the fuzz/ directory in the source? That takes care of this silly class of bugs. In fact I think that's why I use get there.

Sorry, something went wrong.

@phil-opp
Copy link
Contributor Author

I didn't mean that get(2..1) is a bug itself. In the DHCP protocol an option with length 4 has 6 octets (4 + code + length fields) and I thought that TCP was identical. But it seems like in TCP the length field includes the whole option, i.e. length 4 means 4 octets. So no bug here, just a strange difference between the TCP and DHCP option format.

Sorry, something went wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants