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

Guard every with_capacity call with a bounds check #298

Merged
merged 2 commits into from
Feb 13, 2022

Conversation

Swatinem
Copy link
Contributor

@Swatinem Swatinem commented Jan 4, 2022

The crate does a lot of pre-allocation based on untrusted input, which
can lead to unbounded allocation.

This came up in getsentry/symbolic#479, and I see the crate already had some bounds checks for certain parts, though not for Mach-O parsing.

I went a bit overboard and added explicit bounds checks for every place where a with_capacity is called.

The crate does a lot of pre-allocation based on untrusted input, which
can lead to unbounded allocation.
Copy link
Owner

@m4b m4b left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks great, thank you!

@Swatinem
Copy link
Contributor Author

Swatinem commented Feb 4, 2022

I’m sorry for being "that guy", but may I ask for this to be merged and eventually released? ;-)

src/pe/export.rs Outdated
"Buffer is too short for {} address table entries",
address_table_entries
);
return Err(error::Error::Malformed(message));
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m wondering if we should introduce a TooShort(count, &’static str) error variant which would do:

“Buffer is too short for {0} {1}” since you write the same boilerplate message every time (and technically allocate)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea! However I noticed that goblin::Error is not flagged as #[non_exhaustive], so adding a new variant would be technically a breaking change :-(

So how about doing that as a followup at a later time so it does not block releasing this fix.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a breaking change pending anyway, so it’s perfect timing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is good to know, I will do that tomorrow then

@m4b m4b merged commit 8df6e03 into m4b:master Feb 13, 2022
@m4b
Copy link
Owner

m4b commented Feb 13, 2022

Ok merged, @Swatinem thanks for your patience! Hopefully can release this tonight or tomorrow

@m4b
Copy link
Owner

m4b commented Feb 14, 2022

0k goblin 0.5 is out, thanks for your patience!

@m4b
Copy link
Owner

m4b commented Feb 14, 2022

oof, i forgot scroll went to 2021 edition, that's a bit annoying

@m4b
Copy link
Owner

m4b commented Feb 14, 2022

ok i had to yank it, because it's technically broken on the msrv, 1.40; so i have to bump that to edition 2021, which is, unfortunately, 1.56.0 Hopefully we don't have a change of MSRV until the next edition :)

@Swatinem Swatinem deleted the guard-with-capacity branch March 1, 2022 12:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants