0xMiden / 0xMiden/protocol

Prevent memory allocation of untrusted size

Abierto
#1,347 3 comentarios 0 reacciones 0 asignados Ver en GitHub
Lenguaje dominante
Rust
Estrellas
132
Forks
167
Merge medio
1 d 23 h
PR fusionados (30 d)
110

Descripción

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.

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.