Created attachment 12978 [details] An example of an iconv call that causes an assertion failure. When converting UCS4 containing an irreversible character, an assertion failure can occur within __gconv_transform_ucs4_internal. See attachment for an easy reproducible example.
I can confirm this causes an assertion failure. test: ../iconv/skeleton.c:746: __gconv_transform_ucs4_internal: Assertion `outbuf == outerr' failed. Aborted (core dumped)
(In reply to Carlos O'Donell from comment #1) > I can confirm this causes an assertion failure. > > test: ../iconv/skeleton.c:746: __gconv_transform_ucs4_internal: Assertion > `outbuf == outerr' failed. > Aborted (core dumped) I believe the root cause is due to improper bounds used when converting UCS4 to the internal UCS4-like format. I have submitted a patch that I believe should resolve the issue and explains the problem in a bit more depth.
Patch posted: https://sourceware.org/pipermail/libc-alpha/2020-November/119822.html
The fix for bug 18830 may have been the trigger.
Fixed in master. commit 228edd356f03bf62dcf2b1335f25d43c602ee68d Author: Michael Colavita <mcolavita@fb.com> Date: Thu Nov 19 11:44:40 2020 -0500 iconv: Fix incorrect UCS4 inner loop bounds (BZ#26923) Previously, in UCS4 conversion routines we limit the number of characters we examine to the minimum of the number of characters in the input and the number of characters in the output. This is not the correct behavior when __GCONV_IGNORE_ERRORS is set, as we do not consume an output character when we skip a code unit. Instead, track the input and output pointers and terminate the loop when either reaches its limit. This resolves assertion failures when resetting the input buffer in a step of iconv, which assumes that the input will be fully consumed given sufficient output space.
The master branch has been updated by Siddhesh Poyarekar <siddhesh@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=38a9e93cb1c58e3c899d638480e6d6e42af8e6fc commit 38a9e93cb1c58e3c899d638480e6d6e42af8e6fc Author: Siddhesh Poyarekar <siddhesh@sourceware.org> Date: Mon Dec 7 22:29:18 2020 +0530 Add NEWS entry for CVE-2020-29562 (BZ #26923) BZ #26923 now has a CVE entry, so add a NEWS entry for it.
The release/2.31/master branch has been updated by Aurelien Jarno <aurel32@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=0858f46440db4936303de0117908c1de7f4f8215 commit 0858f46440db4936303de0117908c1de7f4f8215 Author: Siddhesh Poyarekar <siddhesh@sourceware.org> Date: Mon Dec 7 22:29:18 2020 +0530 Add NEWS entry for CVE-2020-29562 (BZ #26923) BZ #26923 now has a CVE entry, so add a NEWS entry for it. (cherry picked from commit 38a9e93cb1c58e3c899d638480e6d6e42af8e6fc)
The release/2.27/master branch has been updated by Dmitry Levin <ldv@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=3668134a9ef34b1a96f6b56666ae04886a99d33f commit 3668134a9ef34b1a96f6b56666ae04886a99d33f Author: Siddhesh Poyarekar <siddhesh@sourceware.org> Date: Mon Dec 7 22:29:18 2020 +0530 Add NEWS entry for CVE-2020-29562 (BZ #26923) BZ #26923 now has a CVE entry, so add a NEWS entry for it. (cherry picked from commit 38a9e93cb1c58e3c899d638480e6d6e42af8e6fc)
The release/2.32/master branch has been updated by Dmitry Levin <ldv@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=6fd634e9b922a4a1293f0cf5a8f6c908f68c5401 commit 6fd634e9b922a4a1293f0cf5a8f6c908f68c5401 Author: Siddhesh Poyarekar <siddhesh@sourceware.org> Date: Mon Dec 7 22:29:18 2020 +0530 NEWS: Mention CVE-2020-29562 (BZ #26923) BZ #26923 now has a CVE entry, so add a NEWS entry for it. (cherry picked from commit 38a9e93cb1c58e3c899d638480e6d6e42af8e6fc)