Summary

Inconsistent list state in whitelist management.

Vulnerability Details

Here's the relevant part of the code:

https://github.com/Cyfrin/2024-07-ark-project/blob/273b7b94986d3914d5ee737c99a59ec8728b1517/apps/blockchain/starknet/src/bridge.cairo#L494C8-L514C72

The inconsistency arises from how the new collection is added to the list. Let's break it down:

1. At the beginning, it writes the new collection to the whitelist with (enabled, no_value). This sets the collection as enabled but with no 'next' pointer.

2. If the list is empty (prev.is_zero()), it correctly sets the new collection as the head of the list and returns.

3. If the list is not empty, it finds the last element (or the last active element).

4. After finding the last element, it updates that element's 'next' pointer to point to the new collection: self.white_listed_list.write(prev, (true, collection)).

The inconsistency is that while the last element in the list now points to the new collection, the new collection itself still has its 'next' pointer set to no_value (which was set in step 1).

Here's a practical example:

1. When adding a new collection (let's call it 'NewCol') to a non-empty list:

   • It correctly finds the current last element (let's call it 'LastCol').

   • It updates LastCol to point to NewCol.

   • But it doesn't update NewCol to point to null.

2. This creates a situation like this: Before: Head -> ... -> LastCol -> null

   After: Head -> ... -> LastCol -> NewCol -> [unknown]

   The [unknown] is the problem. It should be null, but it's not set.

Impact

Incomplete list.

Tools Used

Manual review

Recommendations

Update the 'next' pointer of the new collection after inserting it into the list.