In the ScalarQuantAMMBaseStorage contract's quantAMMUnpack32Array function, the stickyEndSourceElem variable is not properly initialized when handling arrays with length less than 8, potentially leading to data corruption or invalid unpacking of storage slots.
The issue exists in the quantAMMUnpack32Array function where stickyEndSourceElem is declared but not initialized for all code paths:
When _targetArrayLength is less than 8, the code skips both initialization paths but still uses stickyEndSourceElem in the sticky end handling section. This uninitialized variable could contain any arbitrary value, leading to incorrect data unpacking.
Incorrect unpacking of storage slots when dealing with arrays of length 1-7 and also silent data corruption as the uninitialized variable might point to a valid but incorrect storage slot. There could also be potential array out-of-bounds access if the uninitialized value exceeds the source array length.
Manual code review
Initialize stickyEndSourceElem for all code paths.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelyhood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.