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. 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. > > 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. > 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. > Gcc chooses to prohibit oversized types when it can easily catch them > and fails compilation stumbling upon an oversized array of a known > constant size (modulo pr68107) but is this a case of undefined behavior, > implementation-defined behavior or what? For non-VLA types, creating a type whose size exceeds the implementation-defined limit is a constraint violation. Violations of constraints are diagnosable; they lead to undefined behavior at runtime. (IMO, the standard is unclear for VLAs but I think the same rule should apply and I'm working to get it clarified to that effect.) > > 3. The same for sizes of objects. There is an environmental limit for > "bytes in an object" but it's marked as "(in a hosted environment > only)". So there is no such limit in the standard for a freestanding > implementation, right? But I doubt that you are supposed to be able to > create oversized arrays (either static or automatic) even in a > freestanding implementation. Again, the limit is implementation-defined, and breaking it is a diagnosable constraint violation.
