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
So this comment isn't specific to the change you're making here, since you're just changing a GNU variable-length array on the stack to an explicit alloca(), which is equivalent. But it's not a good idea to use either a variable-length array on the stack or an alloca() with an unbounded size. This allocation is on the stack, and neither the variable-length array allocation nor the alloca() can actually fail. This can result in stack overflow, which could result in security issues depending on the exact nature of the overflow.
There are basically two ways this could be fixed. Either setting an upper bound on the log message length (and simply truncating if the log message is longer than that), or allocating the buffer on the heap. If you're setting a maximum buffer size anad using the stack, then you may as well just use the fixed maximum size as the size of your array so you don't need alloca(). If you decide to heap allocate, it's probably a good idea to set a maximum size anyway, to reduce the possibility of heap exhaustion and/or attacks based on forcing a lot of heap to be allocated.
Basically: don't use alloca() or variable-sized arrays.
Originally posted by @arai-fortanix in #234 (comment)
The text was updated successfully, but these errors were encountered: