Normally, the table::add
function in Move inserts a new key–value pair into a Table
. It succeeds only if the key does not already exist.
In the PizzaDrop contract, the function that assigns pizza slices to registered users uses table::add
. If a user has already been registered (or maliciously re-registered), the function will abort instead of updating their assigned slice. This breaks expected flow and can cause denial-of-service for that address.
Likelihood:
This occurs whenever the same account is passed to get_random_slice
after having already been inserted once.
Validators or misconfigured owner logic can unintentionally call it again on the same user, triggering aborts.
Impact:
Users can be permanently locked out from receiving a new slice if the owner tries to reassign them.
The contract state may abort mid-transaction, leading to denial-of-service or wasted gas for participants.
If the owner calls register_pizza_lover(deployer, user_addr)
once, it succeeds. A second call for the same user_addr
will hit table::add
again, causing a VM abort (error code not defined in the module). The user will see a transaction revert without the module’s E_NOT_OWNER/E_ALREADY_CLAIMED
codes.
Before adding a new key, check with table::contains
, linke in the example 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.