Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)
Description
Brief/Intro
The contract binds permit updates to current role membership in a way that blocks user revocation during certain admin state transitions. This creates a consent lifecycle flaw, stale migration approvals can revive after role re grant.
Vulnerability Details
The issue is caused by how setMigrationPermit enforces the migrator role check before allowing any permit update. In Staking contract, a user can only write migrationPermits[migrator][user] if that migrator currently has MIGRATOR_ROLE. This creates a state lock condition, a user may successfully set permission to true while the migrator is authorized, but if governance later revokes that role, the same user can no longer call setMigrationPermit(migrator, false) because the call reverts with MigratorNotFound. As a result, the stored approval remains true in state with no user side revocation path during the revoked period. If the same migrator address is granted MIGRATOR_ROLE again in the future, the old approval becomes effective again, and migratePositionsFrom can proceed because it checks role authorization and the existing boolean permit. In short, revocation capability is coupled to current role status, which allows stale migration consent to persist and later reactivate without fresh user intent.
Impact Details
User cannot revoke prior migration consent after role revocation event.
Governance/operator can later re enable the same migrator address and stale approvals become effective without a fresh opt in.
This weakens user control guarantees and can cause unexpected migration execution against user expectations.
