Users can be prevented from using UpliftOnlyExample.addLiquidityProportional by increasing their poolsFeeData[pool][msg.sender].length via LP NFT transfers.
While the addLiquidityProportional function has a check which prevents adding too many LP NFT, the afterUpdate has no such check.
This way malicious user can spam other user with LP NFT to prevent adding liquidity
Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)
Manual Review
Consider implementing a restriction for LP NFT transfers when the poolsFeeData[pool][msg.sender].length exceeds the limit. Consider using an even lower limit for afterUpdate than for addLiquidityProportional or whitelisted senders.
Likelihood: Medium/High, anyone can receive an unlimited NFT number but will cost creation of LP tokens and sending them. Impact: Low/Medium, DoS the afterUpdate and addLiquidityProportional but will be mitigable on-chain because a lot of those NFT can be burn easily in onAfterRemoveLiquidity.
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.