0xMiden / 0xMiden/protocol

Prevent memory allocation of untrusted size

未關閉
#1,347 3 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視
主要語言
Rust
星號
132
分支
167
平均合併
1 天 23 小時
30 天內合併 PR
110

描述

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.

貢獻指南

開啟貢獻指南

評估

這個 Issue 還沒有評估資料。

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。