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

Maybe unsound in ConcurrentMerkleTree #1382

Open
lwz23 opened this issue Dec 9, 2024 · 1 comment
Open

Maybe unsound in ConcurrentMerkleTree #1382

lwz23 opened this issue Dec 9, 2024 · 1 comment

Comments

@lwz23
Copy link

lwz23 commented Dec 9, 2024

hello, thank you for your contribution in this project, I am scanning the unsoundness problem in rust project.
I notice the following code:

pub struct ConcurrentMerkleTree<H, const HEIGHT: usize>
where
    H: Hasher,
{
    pub height: usize,
    pub canopy_depth: usize,

    pub next_index: *mut usize,
    pub sequence_number: *mut usize,
    pub rightmost_leaf: *mut [u8; 32],
.........................
}

impl<H, const HEIGHT: usize> ConcurrentMerkleTree<H, HEIGHT>
where
    H: Hasher,
{
..............................
     pub fn next_index(&self) -> usize {
        unsafe { *self.next_index }
    }
.............................
    pub fn sequence_number(&self) -> usize {
        unsafe { *self.sequence_number }
    }
}

Considering that 'next_index', 'sequence_number', 'rightmost_leaf' are pub field, and sequence_number next_index........ are also pub function. I assume that users can directly manipulate this field. This potential situation could result in *self.sequence_number being dereference a null pointer, and directly dereferencing it might trigger undefined behavior (UB). For safety reasons, I felt it necessary to report this issue. If you have performed checks elsewhere that ensure this is safe, please don’t take offense at my raising this issue.
If there is no external usage for ConcurrentMerkleTree, I suggest it should not marked as pub, at least its field should not marked as pub.

@ananas-block
Copy link
Contributor

Thanks for raising this issue, its a reasonable observation. Agreed, the fields 'next_index', 'sequence_number', 'rightmost_leaf' should be private.

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