CVE-2021-3326: The iconv app in glibc when processing invalid input sequences in the ISO-2022-JP-3 encoding, fails an assertion & aborts

[bhs]

The iconv function in the GNU C Library (aka glibc or libc6) 2.32 and earlier, when processing invalid input sequences in the ISO-2022-JP-3 encoding, fails an assertion in the code path and aborts the program, potentially resulting in a denial of service.

Ref.: https://ubuntu.com/security/CVE-2021-3326

[Florian Weimer (fweimer)]

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.

[Florian Weimer (fweimer)]

Patch posted: https://sourceware.org/pipermail/libc-alpha/2021-January/122058.html

[Florian Weimer (fweimer)]

Fixed for 2.33 via:

commit 7d88c6142c6efc160c0ee5e4f85cde382c072888
Author: Florian Weimer <email address hidden>
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 <email address hidden>

[Steve Beattie (sbeattie)]

This is fixed in hirsute and newer via glibc 2.33.

[Steve Beattie (sbeattie)]

Groovy has reached end of supported status, and as such will not be fixed.

[Michael Hudson-Doyle (mwhudson)]

Does anyone have a test case for this? It seems like it would be good to fix it for focal (and eventually bionic)

[Alex Murray (alexmurray)]

@mwhudson - there is a test case already in the upstream patch: https://sourceware.org/pipermail/libc-alpha/2021-January/122058.html

[Michael Hudson-Doyle (mwhudson)]

I always feel more comfortable for SRUs with a test case that can be run by hand outside the package build, not sure if that's completely justified.

[Michael Hudson-Doyle (mwhudson)]

This got fixed in https://ubuntu.com/security/notices/USN-5310-1