in the whiteList
function:
The function only updates the whitelist status for the given collection but doesn't handle the linked list structure properly.
When disabling a collection (setting enable
to false), it should remove the collection from the linked list to maintain consistency.
When enabling a collection, it should add it to the end of the linked list if it's not already present.
The current implementation may lead to inconsistencies between the white_listed_list
mapping and the actual linked list structure.
This can result in the getWhiteListedCollections
function returning incorrect or incomplete results.
Whitelisted collections being omitted from getWhiteListedCollections
Potentially allowing non-whitelisted collections to be used in deposit_tokens
The inconsistency could lead to allowing unauthorized collections to be bridged between L1 and L2.
It also affects the transparency of the system, as querying whitelisted collections provides inaccurate information.
a. Admin whitelists Collection A
b. Admin whitelists Collection B
c. Admin removes Collection A from whitelist
d. getWhiteListedCollections
still returns both A and B
e. User can still deposit tokens from Collection A, bypassing the whitelist check
To fix this, the function should properly update the linked list structure when enabling or disabling collections, ensuring that the list remains consistent with the whitelist status of each collection.
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.