Tavis Ormandy reported that when converting from ISO-2022-JP-3 to UTF-8, the gconv module could trigger an assertion failure in iconv/skeleton.c if the second wide character in a two-wide-character sequence cannot be written to the output buffer during character set conversion. If glibc is built with assertions, this assertion failure can typically be triggered by applications (such as mail clients) which use the glibc iconv subsystem for MIME character set processing.
Patch posted: https://sourceware.org/pipermail/libc-alpha/2021-January/122058.html
Fixed for 2.33 via: commit 7d88c6142c6efc160c0ee5e4f85cde382c072888 Author: Florian Weimer <fweimer@redhat.com> Date: Wed Jan 27 13:36:12 2021 +0100 gconv: Fix assertion failure in ISO-2022-JP-3 module (bug 27256) The conversion loop to the internal encoding does not follow the interface contract that __GCONV_FULL_OUTPUT is only returned after the internal wchar_t buffer has been filled completely. This is enforced by the first of the two asserts in iconv/skeleton.c: /* We must run out of output buffer space in this rerun. */ assert (outbuf == outerr); assert (nstatus == __GCONV_FULL_OUTPUT); This commit solves this issue by queuing a second wide character which cannot be written immediately in the state variable, like other converters already do (e.g., BIG5-HKSCS or TSCII). Reported-by: Tavis Ormandy <taviso@gmail.com>