0xMiden / 0xMiden/protocol

Prevent memory allocation of untrusted size

Open
#1,347 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
132
Forks
167
Avg merge
1d 23h
Merged PRs (30d)
110

Description

Closely related to https://github.com/facebook/winterfell/issues/377, there are some places where the value we pass to `ByteReader::read_many` can actually be very large. Even with the mentioned issue fixed, we should still prevent passing very large values whose allocation succeeds, but take up, say, 99% of available memory. In those cases, any other panicking memory API in other places could easily panic, because allocation of a small amount of memory would fail. In other words, we may want to put some reasonable limits in place.

This concerns:
- `AssetVault`: The number of assets is serialized as a `usize`.
- `FungibleAssetDelta`: The number of assets is serialized as a `usize`.
- `BlockNoteTree`: The number of leaves is serialized as a `u32`.

For the asset vaults: The question is what limit we can impose to avoid this issue. Perhaps we can limit the number of assets in an account to `u16::MAX`, or if that's too restrictive, then to something like $2^{20}$. Given 32 bytes per asset, that would be a maximum of 2 MiB in the `u16` case or 32 MiB in the $2^{20}$ case.

For the tree: Could this be a `u16`, i.e. match `MAX_OUTPUT_NOTES_PER_BLOCK`? I guess that is technically possible, but if we increase the size of the tree in the future, then that would be a breaking change at the serialization format. So maybe we just enforce a limit at deserialization time and keep `u32` for extensibility.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.