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

flate2 has been creating a slice of uninitialized memory #2008

Closed
KisaragiEffective opened this issue Jul 9, 2024 · 5 comments
Closed

flate2 has been creating a slice of uninitialized memory #2008

KisaragiEffective opened this issue Jul 9, 2024 · 5 comments

Comments

@KisaragiEffective
Copy link
Contributor

@tarcieri
Copy link
Member

tarcieri commented Jul 9, 2024

@KisaragiEffective want to open a PR with an advisory?

@KisaragiEffective
Copy link
Contributor Author

@tarcieri maybe I will, but I'm not going to claim, so feel free to take this if you want :)

@Shnatsel
Copy link
Member

Shnatsel commented Jul 9, 2024

There is no evidence of the uninitialized memory ever being read from or otherwise exposed. And whether the mere existence of uninitialized u8 is acceptable or not was still being debated last time I checked.

So I don't think it warrants an advisory at this point.

We should file one later if either a read from uninit memory is demonstrated (as detected e.g. by Memory Sanitizer) or the Operational Semantics team comes to a conclusion on whether a slice of uninit u8 that is never read from is acceptable or not.

@ChrisDenton
Copy link

whether the mere existence of uninitialized u8 is acceptable or not

As noted by Manish on the issue, uninitialized memory is instantly UB.

@Shnatsel
Copy link
Member

Shnatsel commented Jul 9, 2024

This is not clear-cut. There is no normative document specifying this is UB. The Rust team in charge of writing said document has this on their issue tracker: rust-lang/unsafe-code-guidelines#346 - in particular, it mentions miri not prohibiting the existence of such references.

With the question not being clearly settled even theoretically, and especially with no evidence of any kind of real-world security issue, we're not going to publish an advisory for this and cause a great deal of churn for the whole ecosystem.

I do appreciate this issue report being filed and the problem being brought to our attention. But in this particular instance I do not believe a security advisory is warranted.

@Shnatsel Shnatsel closed this as completed Jul 9, 2024
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

No branches or pull requests

4 participants