You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are several locations where the size of memory to be allocated uses a calculation that can overflow, which can lead to a smaller amount of memory than expected to be allocated, allowing possible heap modification. Indeed, this is currently possible with a crafted BMP image of certain dimensions.
The allocation helper routines in alloc_func.hpp alone suffer from this flaw; namely in the calculation of num_elements * sizeof(T).
This patch attempts to fix this by:
* Checking the internal size calculations in alloc_func.hpp helpers for overflow
* Changing the size parameter for these helpers from size_t to int64, which allows the use of OverflowSafeInt64's in the calculations of other sizes
* Using OverflowSafeInt64s as just mentioned, in size calculations that maybe/are vulnerable to overflow.
* A few size calculations are manually checked.
I have attempted to keep the changes to usages of the alloc_func.hpp helpers minimal but still correct; variables involved in relevant size calculations are simply wrapped with OSI64() (a typedef for OverflowSafeInt64). However, this is still a decently sized patch, and am open to suggestions on how to rework it differently.
Under which circumstances can either of the width or height component of a resolution become more than UINT16 max? The setting is truncated to UINT16_MAX when being read from the configuration file.
Under which circumstances can the width or height component of the chatbox's size become more than UINT16 max? The width is limited to UINT16 max by both its type as the setting validation, the height is limited by the UINT8 max (type and setting validation) of the number of lines setting, and the height of a line is limited by a setting validation to 72. So where would this overflow.
The BMP bit I can agree on, but it might be easier to reject such files just outright. They are not useful; just diallow anything above 16384x16384 would suffice I'd say.
SIZE_MAX is a size_t (unsigned long). Casting it to int64 on x64 makes it effectively -1, disallowing all allocations on x64. If there is an alloca that would be anywhere near SIZE_MAX, that would be very bad. You can never allocate that much. The stack is a few MB on Windows.
So what I am seeing is just a generic: oh, might be wrong so replace it with something that looks much better... but it's actually pointless and makes the code harder to read.