Closed somethingelseentirely closed 1 month ago
Just as an upgrade, I've decided to create a fork that tries to combine the best aspect of minibytes
and ownedbytes
called anybytes
.
I've just discovered some UB in my library that I think also affects minibytes
.
When a Bytes
is created from a Vec<u8>
as the ByteOwner
, then the reference returned fromdowncast_mut
might be reallocated when the Vector is resized. Since the pointer in the Bytes
themselves is not invalidated it can result in a use after free situation.
I don't really need a recent minibytes
release anymore, so feel free to close this issue.
Thank you so much for your work and take care!
Sorry for the late reply and thanks for spotting the UB! It seems we don't use downcast_mut
outside minibytes
itself. So perhaps we can just mark it as a private function.
I think that would be an option, although the act of handing out a & and &mut at the same time alone is probably UB.
I changed the API to return an Arc<T>
, where T
is the type downcast to. That way you can only get mutability if all Bytes with that owner have been dropped.
handing out a & and &mut at the same time
Could you give an example about when that can happen? Given that:
downcast_mut
takes &mut self
which means no as_ref()
slices are handed out.*const u8
instead of &'static [u8]
(like ownerbytes
) so there is no in-struct &
and &mut
being alive at the same time.It's unclear to me how we have &
&mut
borrows both alive at the same time.
Yeah I think you're right, sorry my bad!
FYI minibytes is published now at https://crates.io/crates/sapling-minibytes
Cool! I'll implement the appropriate traits in anybytes
to make them compatible 😄
The minibytes sub-library is way too elegant and useful to be hidden away. It would be great if it was published regularly so that a recent version can just be pulled from crates.io.