https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #33 from Alexander Cherepanov <ch3root at openwall dot com> --- On 2015-11-12 06:25, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065 > > --- Comment #31 from Martin Sebor <msebor at gcc dot gnu.org> --- > (In reply to Alexander Cherepanov from comment #23) > >> 2. The practical problem is size calculation in general, it's not >> limited to sizeof operation. You don't need to use sizeof to create >> oversized automatic VLA (an example in the description). > > Agreed. Creating an automatic VLA object that exhausts the stack is bad. In > all likelihood it will crash the program. I'm not sure to what extent it > might > be exploitable. From http://www.openwall.com/lists/oss-security/2014/11/03/2 : "It can be exploitable in multithreaded programs though if there is an unused stack allocation of at least one page further down in the stack." Sorry, don't have more info off-hand. > Allowing a sizeof expression to overflow given a VLA type is > benign in an of itself, but can lead to more subtle bugs depending on how the > result is used (e.g., to allocate an array on the heap whose elements are then > written to). Some of those bugs have known exploits. Sure. >> 3. IMHO overflow in sizeof operation is UB due to C11, 6.5p5, and >> wrapping according to C11, 6.2.5p9, is not applicable (see the comment #7). > > No, that's not a correct interpretation. It's exactly the other way around. > Sizeof is computed in an unsigned type. IMHO, how sizeof is computed is an implementation detail. C11 doesn't describe it at all. E.g., for arrays it doesn't mention multiplication and just says that "the result is the total number of bytes in the array". From another side: an operand of sizeof is usually not unsigned. Even when the operand is unsigned, sizeof doesn't compute anything with it, sizeof work with its type. >> 4. From the POV of the standard I don't see much difference between VLA >> and ordinary arrays in this question. AFAICT the standard doesn't place >> limits on constructed types of any kind and hence oversized types are >> permitted by the standard. See comment #3 (or pr68107) for a practical >> example of sizeof overflow with an array of a known constant size which >> works with the current gcc. > > It is the intent of the standard to allow implementations to impose such a > limit. It may not be specified with sufficient clarity in the text, but the > intent is reflected in the C99 Rationale. Yeah, it seems to be a known problem without know solution:-) But IMHO: * if C11, 4p6, (about acceptig any strictly conforming program) is really mean what I think it means it should be fixed; * the scope of the problem should be somehow acknowledged and preferably limited in the standard. Something like saying that an implementation can impose any other restrictions but those restrictions must be documented. It's a sad situation when arbitrary limits could be imposed but there is no way for a user to find out which. The ideal illustration here is pr67999. It's a limit which can lead to security problems, which is not documented and which is not detected at compile- or run-time.
