3 ms·
If it's any reassurance, I had a look at it, and although there is unnecessary signed/unsigned arithmetic, I could not find anything exploitable. Change the typ
by eliteraspberrie 13y ago
If it's any reassurance, I had a look at it, and although there is unnecessary signed/unsigned arithmetic, I could not find anything exploitable. Change the types of variables representing an object size, length, array index, and so on to size_t (from int) and it will be fine.
- asveikau 13y agoMight be acceptable for an individual project where you can make statements about the sizes that will be used ahead of time, but for a general purpose library your statement is absolutely false. The issue is that your size requirement can overflow size_t, malloc gets passed a smaller value than you really intended, then if you try to use what you think you allocated (remember, it succeeded with a smaller size), it's a derefence outside the bounds of the allocation. Changing the size or type of the length variable won't solve that. This is a common and well known vulnerability pattern - it is disappointing to see folks so dismissive of it.
- eliteraspberrie 13y agoI'm aware of arithmetic overflow, thanks. It was the subject of my research (which will eventually be open source, watch www.peripetylabs.com/publications/ if you're interested). See my sizeop library in the meantime: https://bitbucket.org/eliteraspberries/sizeop https://bitbucket.org/eliteraspberries/sizeop I am not dismissive of the problem. I just know from experience that the chances of code like that being fixed at all, let alone correctly, is near zero.