When using the delete keyword on a variable of a nested structure, only the top-level fields are reset to their default values. Nested fields within the structure remain unchanged, which can lead to unintended behavior and potential vulnerabilities. This issue is present in the finalizeLock function within the GlobalDataLibrary library of the PredyPool contract.
Proof of Concept
The delete globalData.lockData; line only resets the top-level fields of the lockData structure to their default values. Nested fields within the structure, such as quoteReserve, baseReserve, locker, and pairId, are not explicitly reset, which can lead to residual data remaining in these fields.
delete globalData.lockData;
Example Scenario:
Before Deletion:globalData.lockData contains the following data:
Lines of code
https://github.com/code-423n4/2024-05-predy/blob/a9246db5f874a91fb71c296aac6a66902289306a/src/types/GlobalData.sol#L69
Vulnerability details
Impact
When using the
delete
keyword on a variable of a nested structure, only the top-level fields are reset to their default values. Nested fields within the structure remain unchanged, which can lead to unintended behavior and potential vulnerabilities. This issue is present in thefinalizeLock
function within theGlobalDataLibrary
library of thePredyPool
contract.Proof of Concept
The
delete globalData.lockData;
line only resets the top-level fields of thelockData
structure to their default values. Nested fields within the structure, such asquoteReserve
,baseReserve
,locker
, andpairId
, are not explicitly reset, which can lead to residual data remaining in these fields.Example Scenario:
globalData.lockData
contains the following data:lockData
field is reset, but nested fields may retain their previous values.Tools Used
Manual
Recommended Mitigation Steps
Ensure that each nested field within the
lockData
structure is explicitly deleted before deleting the outer structure.Assessed type
Other