Tokens are pulled from users without verifying pool status contrary to requirement

[howlbot-integration]

Lines of code

https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/seawater/src/lib.rs#L679-L687
https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/seawater/src/lib.rs#L716-L738

Vulnerability details

Proof of Concept

Both the update_position_internal() and adjust_position_internal() functions are responsible for managing token positions, which involves taking tokens from users. However, there is a critical inconsistency in how each function verifies the operational status of the liquidity pool before performing token transfers from the user.

update_position_internal()
This function checks if the pool is enabled before taking tokens from the user.

            // if we're TAKING, make sure that the pool is enabled.
            assert_or!(pool.enabled.get(), Error::PoolDisabled);
            ---SNIP---
            erc20::take(pool_addr, token_0.abs_pos()?, permit_0)?;
            erc20::take(FUSDC_ADDR, token_1.abs_pos()?, permit_1)?;

adjust_position_internal()
This does not explicitly check whether the pool is enabled before proceeding.

    let (amount_0, amount_1) =
            self.pools
                .setter(pool)
                .adjust_position(id, amount_0_desired, amount_1_desired)?;
    ---SNIP---
    erc20::take(pool, amount_0, permit_0)?;
    erc20::take(FUSDC_ADDR, amount_1, permit_1)?;

First, it calls self.pools.setter(pool).adjust_position(...) which has the following comment:

    // [update_position] should also ensure that we don't do this on a pool that's not currently running
    self.update_position(id, delta)

The comment in the adjust_position() function implies that a check for the pool's operational state is necessary and should be enforced in update_position(). However, update_position() function does not make such enforcement as it does not check for pool status.

Impact

Users could unintentionally have their tokens adjusted or transferred to a pool that is not operational which is not in accordance with protocol requirement. This also exposes users to risks in the event that there are potential issues with the pool.

Recommended Mitigation Steps

Modify the adjust_position_internal() function to include a status check before executing the position adjustment:

    // Ensure the pool is enabled before making any adjustments
+   assert_or!(pool.enabled.get(), Error::PoolDisabled);

Assessed type

Other

[c4-judge]

alex-ppg marked the issue as unsatisfactory:
Invalid

[c4-judge]

alex-ppg marked the issue as selected for report

[c4-judge]

alex-ppg marked the issue as satisfactory

[af-afk]

Fix: fluidity-money/long.so@8205999
fluidity-money/long.so@d022721