I am not sure why the share_length and secret_length variables are defined as type uint32_t but both are being compared to a uint8_t in a loop condition. This causes CodeQL to give a high severity security warning. 'High Severity' is probably a bit alarmist but in a loop condition, comparison of a value of a narrow type with a value of a wide type may result in unexpected behaviour if the wider value is sufficiently large (or small). This is because the narrower value may overflow. This can lead to an infinite loop.
This PR fixes #42 by casting share_length and secret_length to uint8_t ensuring comparison of same types. If type casting is not the solution then maybe share_length and secret_length should be declared as uint8_t not uint32_t?
Note: I chose to cast to the narrower uint8_t rather than declaring j as the wider uint32_t as I think neither share_length or secret_lengthshould ever be bigger than 255.
Hi,
I am not sure why the
share_lengthandsecret_lengthvariables are defined as typeuint32_tbut both are being compared to auint8_tin a loop condition. This causes CodeQL to give a high severity security warning. 'High Severity' is probably a bit alarmist but in a loop condition, comparison of a value of a narrow type with a value of a wide type may result in unexpected behaviour if the wider value is sufficiently large (or small). This is because the narrower value may overflow. This can lead to an infinite loop.See here for further explanation of the warning: Comparison of narrow type with wide type in loop condition
This PR fixes #42 by casting
share_lengthandsecret_lengthtouint8_tensuring comparison of same types. If type casting is not the solution then maybeshare_lengthandsecret_lengthshould be declared asuint8_tnotuint32_t?Note: I chose to cast to the narrower
uint8_trather than declaringjas the wideruint32_tas I think neithershare_lengthorsecret_lengthshould ever be bigger than 255.