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

Unsafe usage of from_raw_parts and from_raw_parts_mut #52

Open
Dzejkop opened this issue Jun 28, 2023 · 1 comment
Open

Unsafe usage of from_raw_parts and from_raw_parts_mut #52

Dzejkop opened this issue Jun 28, 2023 · 1 comment

Comments

@Dzejkop
Copy link
Contributor

Dzejkop commented Jun 28, 2023

We use these functions in a few places without ensuring that the types we're converting into can be converted to.

For example:

    pub fn new_with_initial_values(
        file_path: PathBuf,
        initial_value: &H::Hash,
        storage_size: usize,
    ) -> Result<Self, DenseMMapError> {
        let size_of_val = std::mem::size_of_val(initial_value);
        let initial_vals: Vec<H::Hash> = vec![initial_value.clone(); storage_size];

        // cast Hash pointer to u8 pointer
        let ptr = initial_vals.as_ptr().cast::<u8>();

        let size_of_buffer: usize = storage_size * size_of_val;

        let buf: &[u8] = unsafe {
            // moving pointer by u8 for storage_size * size of hash would get us the full
            // buffer
            std::slice::from_raw_parts(ptr, size_of_buffer)
        };

H::Hash could be a type that contains padding which would put as in UB land.

We should use the bytemuck crate and demand that H::Hash is Pod

This also applies to the Deref and DerefMut impls.

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

2 participants
@Dzejkop and others