Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Should there be informational advisories against old versions of crates that construct uninitialized integers? #1194

Closed
saethlin opened this issue Feb 15, 2022 · 1 comment

Comments

@saethlin
Copy link
Contributor

The standard library has a stern warning against use of mem::uninitialized that it sort of walks back at the end:

Worse, truly uninitialized memory like what gets returned here is special in that the compiler knows that it does not have a fixed value. This makes it undefined behavior to have uninitialized data in a variable even if that variable has an integer type. (Notice that the rules around uninitialized integers are not finalized yet, but until they are, it is advisable to avoid them.)

There has been a slow but very broad ecosystem move away from this function. For example, itoa published a 1.0 release 2 months ago which removes use of this function. bytes used to use it too, as well as crossbeam. I've run cargo audit on crates that depend on versions of these crates which call mem::uninitialized and I don't come up with anything for itoa, bytes, or crossbeam. I've selected these crates specifically to call out, because I know they construct uninit instances of u8 or usize and I know that pre-patch versions of them are in use.

I think it would be fair to indicate to users that they should upgrade, given how long it's been since a patch and that itoa changed basically not at all with 1.0. But does "constructs uninit integers" meet the bar for a RustSec advisory in light of the fact that it's definitely a bad idea, but unclear if it's UB? It's unclear to my mind if this is the same kind of thing as assuming the layout of SocketAddr.

@saethlin
Copy link
Contributor Author

Oh this should definitely be a Discussion sigh

@rustsec rustsec locked and limited conversation to collaborators Feb 15, 2022
@tarcieri tarcieri converted this issue into discussion #1195 Feb 15, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant