misc/error.c:error_tail, in the conversion code for when stderr is wide-oriented, calculates an allocation size as (len * sizeof (wchar_t)) without checking if that might overflow, as it would for a 1GB string on a 32-bit system.

It seems unlikely for an application to call error with an untrusted error string that is nevertheless known to be a valid printf format string (if it's not checked to be a valid format string, at least without %n, there's a much more simple exploit), but obviously such an allocation should be checked in any case.