-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
io: extend Buf
length only after having read into it
#7054
base: master
Are you sure you want to change the base?
io: extend Buf
length only after having read into it
#7054
Conversation
e64152a
to
a2a4b8a
Compare
Please add a test that would catch the unsoundness in question if run under miri. |
5759994
to
064afef
Compare
I don't think this qualifies as a security issue, because tokio/tokio/src/io/poll_evented.rs Lines 168 to 169 in 9d42b97
Still, I agree that the particular implementation is not the greatest. We should avoid calling |
064afef
to
8ec1726
Compare
Buf::ensure_capacity_for
Vec::set_len
only after having read into it
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.
I'm not too happy about the current &mut [MaybeUninit<u8>]
-> &mut [u8]
hacks but given that everything else also relies on it I've changed it here too
8ec1726
to
c95f8a6
Compare
Vec::set_len
only after having read into itBuf
length only after having read into it
Motivation
I've discovered that
Buf::ensure_capacity_for
is unsound because it usesVec::set_len
to grow theVec
past the init area. This violates the documented safety invariants ofVec::set_len
, which say The elements atold_len..new_len
must be initialized.This can be tested very easily by adding
for &byte in &self.buf {}
after theself.buf.set_len
call.Solution
Have reads use the spare capacity of
buf
andVec::set_len
afterwards.