QuantAMM

Summary

The quantAMMUnpack32Array function in ScalarQuantAMMBaseStorage contains an integer overflow vulnerability in its numeric scaling operations. The function unpacks storage slots containing multiple 32-bit integers and applies scaling differently for the first unpacked value versus subsequent values:

https://github.com/Cyfrin/2024-12-quantamm/blob/main/pkg/pool-quantamm/contracts/QuantAMMStorage.sol#L143

And in the sticky end handling:

https://github.com/Cyfrin/2024-12-quantamm/blob/main/pkg/pool-quantamm/contracts/QuantAMMStorage.sol#L197

This inconsistency in type casting before multiplication creates potential for overflow. The first value gets shifted and multiplied without int32 bounds, while subsequent values are constrained to int32 before multiplication. When matching this with the packing function:

This creates an asymmetric situation where values that were accepted during packing could overflow during unpacking due to the different handling of the first versus subsequent values.

Impact

Given this is used for AMM pool state calculations, the overflow could corrupt variance and gradient values used in price calculations. The inconsistent handling means the corruption would affect some values in a packed slot differently than others, leading to unpredictable mathematical behavior in pool operations.

Would you like me to continue with the mitigation steps?.

Recommended mitigation steps

1. Perform the multiplication after casting to int256:

1. Add explicit bounds checking:

1. Make scaling consistent between pack and unpack operations: