We should reject impossibly large size arguments for snprintf, vsprintf. This is similar to bug 13592. Passing (size_t)-1 to snprintf to emulate the sprintf behavior might actually be valid code, so this would have to be restricted to -D_FORTIFY_SOURCE mode. This is prompted by <https://lists.exim.org/lurker/message/20121026.080330.74b9147b.en.html> (CVE-2012-5671).
Did you post a patch since sending this bug?
snprintf is required by POSIX to return a negative value and set errno to EOVERFLOW if the n argument is greater than INT_MAX. Actually I find it difficult to see how this requirement is compatible with ISO C, which makes no such requirement or allowance for what would otherwise be a spurious error, so perhaps this should be filed as a bug against POSIX; an interpretation is needed, at least. But assuming the requirement in POSIX stands, it's a bug for glibc not to report an error when n is greater than INT_MAX.
I've reported the issue with the possible conflict between the standards on the Austin Group tracker here: http://austingroupbugs.net/view.php?id=761
The Austin Group has decided not to updated POSIX.
Patch posted: https://sourceware.org/ml/libc-alpha/2013-10/msg00630.html
The Austin Group appears to have failed to address the conflict with C11 semantics. Is the Austin Group / WG14 liaison taking this up with WG14, if the Austin Group view is that the C11 specifications are defective? A fortification check obviously doesn't address the POSIX semantics, so a separate bug would need opening for those if this one is considered to be about fortification only.
*** Bug 29379 has been marked as a duplicate of this bug. ***