The AaveDIVAWrapper::constructor()
incorrectly passes parameters to its mother contract, AaveDIVAWrapperCore::constructor()
. Consequently, the AaveDIVAWrapper
contract can be bricked after deployment.
The AaveDIVAWrapper::constructor()
receives the _aaveV3Pool
, _diva
, and _owner
as parameters and respectively passes them (see @1
in the snippet below) to its mother contract, AaveDIVAWrapperCore::constructor()
.
However, the AaveDIVAWrapperCore::constructor()
(i.e., the mother contract) defines its parameters in a different order (refer to @2.1
). Instead of receiving the aaveV3Pool_
and then diva_
, it expects the opposite order.
Hence, the AaveDIVAWrapperCore::constructor()
will eventually assign the immutable variables _diva
and _aaveV3Pool
erroneously (@2.2
), rendering the AaveDIVAWrapper
contract to be bricked after deployment.
In addition to the test script, we noticed that the setup()
wrongly passes the parameters in the opposite order (@3
) of the AaveDIVAWrapper::constructor()
's requirement.
This mistake makes the test script runnable, fortunately. That's the reason why the test script cannot detect this mis-implementation.
Note: this is not about the admin-input mistake issue but the incorrect implementation of the
AaveDIVAWrapper::constructor()
.
The impact is considered low (there are no direct financial problems, but the AaveDIVAWrapper
contract cannot operate after deployment with the correct order of parameters).
The likelihood is high (if an admin deploys the contract by inputting arguments to the AaveDIVAWrapper::constructor()
in the correct order, the issue will arise).
For this reason, this issue deserves a medium.
Manual Review
Improve the order of parameters of the AaveDIVAWrapper::constructor()
to be consistent with that of the AaveDIVAWrapperCore::constructor()
, as in the snippet below.
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.