Missing update current tick when we call set_sqrt_price_F_F_4_D_B_98_C()

[howlbot-integration]

Lines of code

https://github.com/code-423n4/2024-08-superposition/blob/4528c9d2dbe1550d2660dac903a8246076044905/pkg/seawater/src/lib.rs#L1078-L1092

Vulnerability details

Impact

When we update the sqrt price via set_sqrt_price_F_F_4_D_B_98_C(), the pool's cur tick is not updated timely. This will cause that cur_tick is incorrect. Calculations based on cur_tick will be wrong.

Proof of Concept

In lib.rs, if one pool is misconfigured at the beginning of the pool's life, we can update the pool's sqrt price via function set_sqrt_price_F_F_4_D_B_98_C().
The problem is that the pool's cur tick is calculated based on the sqrt price. We only update the sqrt price, missing update the cur_tick.

For example:

• Init this pool with one incorrect sqrt price, cur_tick will be calculated based on the incorrect sqrt price.
• Then we update sqrt price via function set_sqrt_price_F_F_4_D_B_98_C.
  But the cur_tick is still incorrect.

    pub fn set_sqrt_price_F_F_4_D_B_98_C(
        &mut self,
        pool: Address,
        new_price: U256,
    ) -> Result<(), Revert> {
        assert_eq_or!(
            msg::sender(),
            self.seawater_admin.get(),
            Error::SeawaterAdminOnly
        );
        // @audit if we set the sqrt price incorrectly, and we want to set the price correctly, we should update the cur_tick together.
        self.pools.setter(pool).set_sqrt_price(new_price);

        Ok(())
    }

Tools Used

Manual

Recommended Mitigation Steps

Update the related cur_tick when we update the sqrt price.

Assessed type

Context

[af-afk]

We won't fix this, since the admin is responsible for calling this path, and it should be aware of the risks/issues involved. It would be better to include another function that sets the current tick.

[alex-ppg]

The Warden outlines that the administrative function configuring the square root price of a particular pool will not update its current tick immediately, however, the submission fails to pinpoint the impact accurately other than a vague identification that the current tick would be incorrect.

Given the administrative nature of the function and the lack of adequate substantiation as to why the change would be harmful, I am inclined to consider this a QA caveat that should be documented for administrators who interact with the system.

[c4-judge]

alex-ppg changed the severity to QA (Quality Assurance)

[c4-judge]

alex-ppg marked the issue as grade-b

[c4-judge]

alex-ppg marked the issue as grade-c

[c4-judge]

alex-ppg marked the issue as grade-b