A security flaw has been discovered in musl libc up to 1.2.6. Affected is the function iconv of the file src/locale/iconv.c of the component GB18030 4-byte Decoder. Performing a manipulation results in inefficient algorithmic complexity. The attack must be initiated from a local position. To fix this issue, it is recommended to deploy a patch.

An issue was discovered in musl libc 0.7.10 through 1.2.6. Stack-based memory corruption can occur during qsort of very large arrays, due to incorrectly implemented double-word primitives. The number of elements must exceed about seven million, i.e., the 32nd Leonardo number on 32-bit platforms (or the 64th Leonardo number on 64-bit platforms, which is not practical).

The following CVE has been assigned to this issue:

CVE-2026-6042 On 2 Apr 2026, at 22.27, Jens Jarl Nestén Hansen-Nord <jens () nesten eu> wrote:

========================================== libc musl Security Advisory: April 2, 2026 ========================================== Description: The GB18030 4-byte decoder in musl libc's iconv() implementation contains a gap-skipping loop that performs a full linear scan of the gb18030126 lookup table (23,940 entries) on each iteration of an outer loop whose iteration count is input-dependent. For 4-byte sequences whose linear index falls just below the dense CJK Unified Ideographs range, the outer loop executes approximately 20,905 times, resulting in approximately 500 million comparisons per input character. Classification: Inefficient Algorithmic Complexity (CWE-407) Impact: This allows a remote attacker to cause denial of service via CPU exhaustion by sending a crafted GB18030 payload to any network service that uses musl's iconv() for character encoding conversion. Measured on musl 1.2.6 and 1.2.5: a single 4-byte input character (bytes 0x82 0x35 0x8F 0x33) takes approximately 260ms to decode, compared to approximately 13 microseconds for a benign character — a 19,000x slowdown. A payload of 40kB will take ~43 minutes to decode.

Versions affected: musl 0.8.0 to 1.2.6

Status: The issue has been confirmed and fixed by maintainer, Rich Felker. A CVE has been requested and is pending assignment.

Reported by: Jens Jarl Nestén Hansen-Nord

Upstream fix: Iconv-gb18030-fix.diff

diff --git a/src/locale/iconv.c b/src/locale/iconv.c index 52178950..e559aa4c 100644 --- a/src/locale/iconv.c +++ b/src/locale/iconv.c @@ -74,6 +74,10 @@ static const unsigned short gb18030[126][190] = { #include "gb18030.h" }; +static const unsigned short gb18030utf[][2] = { +#include "gb18030utf.h" +}; + static const unsigned short big5[89][157] = { #include "big5.h" }; @@ -224,6 +228,8 @@ static unsigned unitojis(unsigned c) } } +#define countof(a) (sizeof (a) / sizeof (a)) + sizet iconv(iconvt cd, char restrict in, sizet restrict inb, char restrict out, sizet restrict outb) { sizet x=0; @@ -430,16 +436,14 @@ sizet iconv(iconvt cd, char restrict in, sizet restrict inb, char restri d = ((unsigned char )in + 3); if (d-'0'>9) goto ilseq; c += d-'0'; - c += 128; - for (d=0; d<=c; ) { - k = 0; - for (int i=0; i<126; i++) - for (int j=0; j<190; j++) - if (gb18030[i][j]-d <= c-d) - k++; - d = c+1; - c += k; + for (int i=0; i<countof(gb18030utf); i++) { + if (c<gb18030utf[i][1]) { + c += gb18030utf[i][0]; + break; + } + c -= gb18030utf[i][1]; } + c += 0x10000; break; } d -= 0x40;

On Thu, Apr 02, 2026 at 08:45:57PM -0400, Rich Felker wrote: On Thu, Apr 02, 2026 at 10:27:38PM +0200, Jens Jarl Nestén Hansen-Nord wrote: ========================================== libc musl Security Advisory: April 2, 2026 ========================================== Description: The GB18030 4-byte decoder in musl libc's iconv() implementation contains a gap-skipping loop that performs a full linear scan of the gb18030126 lookup table (23,940 entries) on each iteration of an outer loop whose iteration count is input-dependent. For 4-byte sequences whose linear index falls just below the dense CJK Unified Ideographs range, the outer loop executes approximately 20,905 times, resulting in approximately 500 million comparisons per input character. Classification: Inefficient Algorithmic Complexity (CWE-407) Impact: This allows a remote attacker to cause denial of service via CPU exhaustion by sending a crafted GB18030 payload to any network service that uses musl's iconv() for character encoding conversion. Measured on musl 1.2.6 and 1.2.5: a single 4-byte input character (bytes 0x82 0x35 0x8F 0x33) takes approximately 260ms to decode, compared to approximately 13 microseconds for a benign character — a 19,000x slowdown. A payload of 40kB will take ~43 minutes to decode.

Versions affected: musl 0.8.0 to 1.2.6

Status: The issue has been confirmed and fixed by maintainer, Rich Felker. A CVE has been requested and is pending assignment.

Reported by: Jens Jarl Nestén Hansen-Nord

Upstream fix: Iconv-gb18030-fix.diff

diff --git a/src/locale/iconv.c b/src/locale/iconv.c index 52178950..e559aa4c 100644 --- a/src/locale/iconv.c +++ b/src/locale/iconv.c @@ -74,6 +74,10 @@ static const unsigned short gb18030[126][190] = { #include "gb18030.h" }; +static const unsigned short gb18030utf[][2] = { +#include "gb18030utf.h" +}; + static const unsigned short big5[89][157] = { #include "big5.h" }; @@ -224,6 +228,8 @@ static unsigned unitojis(unsigned c) } } +#define countof(a) (sizeof (a) / sizeof (a)) + sizet iconv(iconvt cd, char restrict in, sizet restrict inb, char restrict out, sizet restrict outb) { sizet x=0; @@ -430,16 +436,14 @@ sizet iconv(iconvt cd, char restrict in, sizet restrict inb, char restri d = ((unsigned char )in + 3); if (d-'0'>9) goto ilseq; c += d-'0'; - c += 128; - for (d=0; d<=c; ) { - k = 0; - for (int i=0; i<126; i++) - for (int j=0; j<190; j++) - if (gb18030[i][j]-d <= c-d) - k++; - d = c+1; - c += k; + for (int i=0; i<countof(gb18030utf); i++) { + if (c<gb18030utf[i][1]) { + c += gb18030utf[i][0]; + break; + } + c -= gb18030utf[i][1]; } + c += 0x10000; break; } d -= 0x40; The above patch was a proposal for testing. It should mitigate the extreme slowness for characters encoded in GB18030's UTF, but it does not work correctly and has not been confirmed not to have other problems. I will follow up with a correct patch. The attached patch has now been tested to work. Compared to the previous version above, it corrects one value in the table, an erroneous += 0x10000 above, and missing logic for characters U+10000 and up.

Rich

On Thu, Apr 02, 2026 at 10:27:38PM +0200, Jens Jarl Nestén Hansen-Nord wrote: ========================================== libc musl Security Advisory: April 2, 2026 ========================================== Description: The GB18030 4-byte decoder in musl libc's iconv() implementation contains a gap-skipping loop that performs a full linear scan of the gb18030126 lookup table (23,940 entries) on each iteration of an outer loop whose iteration count is input-dependent. For 4-byte sequences whose linear index falls just below the dense CJK Unified Ideographs range, the outer loop executes approximately 20,905 times, resulting in approximately 500 million comparisons per input character. Classification: Inefficient Algorithmic Complexity (CWE-407) Impact: This allows a remote attacker to cause denial of service via CPU exhaustion by sending a crafted GB18030 payload to any network service that uses musl's iconv() for character encoding conversion. Measured on musl 1.2.6 and 1.2.5: a single 4-byte input character (bytes 0x82 0x35 0x8F 0x33) takes approximately 260ms to decode, compared to approximately 13 microseconds for a benign character — a 19,000x slowdown. A payload of 40kB will take ~43 minutes to decode.

Versions affected: musl 0.8.0 to 1.2.6

Status: The issue has been confirmed and fixed by maintainer, Rich Felker. A CVE has been requested and is pending assignment.

Reported by: Jens Jarl Nestén Hansen-Nord

Upstream fix: Iconv-gb18030-fix.diff

diff --git a/src/locale/iconv.c b/src/locale/iconv.c index 52178950..e559aa4c 100644 --- a/src/locale/iconv.c +++ b/src/locale/iconv.c @@ -74,6 +74,10 @@ static const unsigned short gb18030[126][190] = { #include "gb18030.h" }; +static const unsigned short gb18030utf[][2] = { +#include "gb18030utf.h" +}; + static const unsigned short big5[89][157] = { #include "big5.h" }; @@ -224,6 +228,8 @@ static unsigned unitojis(unsigned c) } } +#define countof(a) (sizeof (a) / sizeof (a)) + sizet iconv(iconvt cd, char restrict in, sizet restrict inb, char restrict out, sizet restrict outb) { sizet x=0; @@ -430,16 +436,14 @@ sizet iconv(iconvt cd, char restrict in, sizet restrict inb, char restri d = ((unsigned char )in + 3); if (d-'0'>9) goto ilseq; c += d-'0'; - c += 128; - for (d=0; d<=c; ) { - k = 0; - for (int i=0; i<126; i++) - for (int j=0; j<190; j++) - if (gb18030[i][j]-d <= c-d) - k++; - d = c+1; - c += k; + for (int i=0; i<countof(gb18030utf); i++) { + if (c<gb18030utf[i][1]) { + c += gb18030utf[i][0]; + break; + } + c -= gb18030utf[i][1]; } + c += 0x10000; break; } d -= 0x40; The above patch was a proposal for testing. It should mitigate the extreme slowness for characters encoded in GB18030's UTF, but it does not work correctly and has not been confirmed not to have other problems. I will follow up with a correct patch.

Rich

========================================== libc musl Security Advisory: April 2, 2026 ========================================== Description: The GB18030 4-byte decoder in musl libc's iconv() implementation contains a gap-skipping loop that performs a full linear scan of the gb18030126 lookup table (23,940 entries) on each iteration of an outer loop whose iteration count is input-dependent. For 4-byte sequences whose linear index falls just below the dense CJK Unified Ideographs range, the outer loop executes approximately 20,905 times, resulting in approximately 500 million comparisons per input character. Classification: Inefficient Algorithmic Complexity (CWE-407) Impact: This allows a remote attacker to cause denial of service via CPU exhaustion by sending a crafted GB18030 payload to any network service that uses musl's iconv() for character encoding conversion. Measured on musl 1.2.6 and 1.2.5: a single 4-byte input character (bytes 0x82 0x35 0x8F 0x33) takes approximately 260ms to decode, compared to approximately 13 microseconds for a benign character — a 19,000x slowdown. A payload of 40kB will take ~43 minutes to decode.

Versions affected: musl 0.8.0 to 1.2.6

Status: The issue has been confirmed and fixed by maintainer, Rich Felker. A CVE has been requested and is pending assignment.

Reported by: Jens Jarl Nestén Hansen-Nord

Upstream fix: Iconv-gb18030-fix.diff

diff --git a/src/locale/iconv.c b/src/locale/iconv.c index 52178950..e559aa4c 100644 --- a/src/locale/iconv.c +++ b/src/locale/iconv.c @@ -74,6 +74,10 @@ static const unsigned short gb18030[126][190] = { #include "gb18030.h" }; +static const unsigned short gb18030utf[][2] = { +#include "gb18030utf.h" +}; + static const unsigned short big5[89][157] = { #include "big5.h" }; @@ -224,6 +228,8 @@ static unsigned unitojis(unsigned c) } } +#define countof(a) (sizeof (a) / sizeof (a)) + sizet iconv(iconvt cd, char restrict in, sizet restrict inb, char restrict out, sizet restrict outb) { sizet x=0; @@ -430,16 +436,14 @@ sizet iconv(iconvt cd, char restrict in, sizet restrict inb, char restri d = ((unsigned char )in + 3); if (d-'0'>9) goto ilseq; c += d-'0'; - c += 128; - for (d=0; d<=c; ) { - k = 0; - for (int i=0; i<126; i++) - for (int j=0; j<190; j++) - if (gb18030[i][j]-d <= c-d) - k++; - d = c+1; - c += k; + for (int i=0; i<countof(gb18030utf); i++) { + if (c<gb18030utf[i][1]) { + c += gb18030utf[i][0]; + break; + } + c -= gb18030utf[i][1]; } + c += 0x10000; break; } d -= 0x40;

El vie, 14 feb 2025, 07:14, Nick Wellnhofer <wellnhofer () aevum de> escribió: On Feb 13, 2025, at 23:28, Daniel Gutson <danielgutson () gmail com> wrote: Curious: is there any info about how this was discovered? The bug was discovered with basic fuzz testing. As libxml2 maintainer, I found more and more issues in various iconv implementations by accident which is a strong indicator that all this code isn't tested enough. The iconv API is also trivial to fuzz, so it seemed like a nice weekend project. Thanks, AFL?

My work is related to static checkers and linters (we will contribute an important patch to weggli soon), so I was wondering if you used something that used symbolic execution.

Nice job! Nick

On Feb 13, 2025, at 23:28, Daniel Gutson <danielgutson () gmail com> wrote: Curious: is there any info about how this was discovered? The bug was discovered with basic fuzz testing. As libxml2 maintainer, I found more and more issues in various iconv implementations by accident which is a strong indicator that all this code isn't tested enough. The iconv API is also trivial to fuzz, so it seemed like a nice weekend project.

Nick

On Thu, Feb 13, 2025 at 07:28:29PM -0300, Daniel Gutson wrote: Curious: is there any info about how this was discovered? The reporter emailed me off-list with two iconv bug findings, out of caution in case they turned out to be security relevant, but didn't think they were big. I worked out that the EUC-KR one would allow controlled writes by advancing the output pointer back past the start without writing anything until the next valid conversion.

I'm not sure if any tools were used, but IMO both were definitely things you could find with an in-depth manual read of the source looking for mistakes. CC'ing Nick Wellnhofer in case he has more to add on this.

Rich El jue, 13 feb 2025, 14:16, Rich Felker <dalias () libc org> escribió: Vulnerability description:

A vulnerability has been identified in musl libc's implementation of iconv that can result in out-of-bounds memory writes in applications which process untrusted input using iconv and where the input charset for the conversion is input-controlled.

In order for the vulnerability to be exposed, an application must call iconvopen with an output encoding of UTF-8 and and input encoding of EUC-KR, and must subsequently process untrusted input using the resulting conversion descriptor. The most common scenario in which this occurs is using the declared MIME charset of untrusted input (for example, in XML, HTML, or MIME-encoded email) as input to iconvopen for converting arbitrary-encoding input to UTF-8.

This issue was discovered and reported by Nick Wellnhofer. It arose as a combination of incorrect input byte validation in the EUC-KR decoder, and the fact that the UTF-8 output encoder assumed an invariant that the input decoder never produces character codes which are not valid Unicode Scalar Values.

Affected versions:

The vulnerable code has been present since EUC-KR support was added to iconv in musl 0.9.13. All versions in the range 0.9.13 through 1.2.5 are affected.

Future releases beginning with 1.2.6 will ship with the bug fixed.

Mitigation:

All users should apply the source patches included/attached below. The first fixes the bug (incorrect input byte validation) responsible for the vulnerability, and the second closes off the vector by which this class of bug escalated to an out-of-bounds write. These patches should apply cleanly to all versions affected by the bug.

Users of musl libc based distributions should obtain an updated package with the patch applied through their distributon's update channels.

Static-linked binaries that cannot easily be relinked may be patched to inhibit the vulnerability, at the cost of disabling support for decoding EUC-KR text, by searching the binary, using a binary-clean/hex editor, for the byte sequence:

"euckr\0ksc5601\0ksx1001\0cp949\0"

and replacing it with:

"-----\0-------\0-------\0-----\0"

Since non-alphanumeric-ASCII characters are stripped from the charset name by iconvopen, this change will render EUC-KR and all aliases for it unmatchable, thereby making the vulnerable code unreachable.

Curious: is there any info about how this was discovered?

El jue, 13 feb 2025, 14:16, Rich Felker <dalias () libc org> escribió: Vulnerability description:

A vulnerability has been identified in musl libc's implementation of iconv that can result in out-of-bounds memory writes in applications which process untrusted input using iconv and where the input charset for the conversion is input-controlled.

In order for the vulnerability to be exposed, an application must call iconvopen with an output encoding of UTF-8 and and input encoding of EUC-KR, and must subsequently process untrusted input using the resulting conversion descriptor. The most common scenario in which this occurs is using the declared MIME charset of untrusted input (for example, in XML, HTML, or MIME-encoded email) as input to iconvopen for converting arbitrary-encoding input to UTF-8.

This issue was discovered and reported by Nick Wellnhofer. It arose as a combination of incorrect input byte validation in the EUC-KR decoder, and the fact that the UTF-8 output encoder assumed an invariant that the input decoder never produces character codes which are not valid Unicode Scalar Values.

Affected versions:

The vulnerable code has been present since EUC-KR support was added to iconv in musl 0.9.13. All versions in the range 0.9.13 through 1.2.5 are affected.

Future releases beginning with 1.2.6 will ship with the bug fixed.

Mitigation:

All users should apply the source patches included/attached below. The first fixes the bug (incorrect input byte validation) responsible for the vulnerability, and the second closes off the vector by which this class of bug escalated to an out-of-bounds write. These patches should apply cleanly to all versions affected by the bug.

Users of musl libc based distributions should obtain an updated package with the patch applied through their distributon's update channels.

Static-linked binaries that cannot easily be relinked may be patched to inhibit the vulnerability, at the cost of disabling support for decoding EUC-KR text, by searching the binary, using a binary-clean/hex editor, for the byte sequence:

"euckr\0ksc5601\0ksx1001\0cp949\0"

and replacing it with:

"-----\0-------\0-------\0-----\0"

Since non-alphanumeric-ASCII characters are stripped from the charset name by iconvopen, this change will render EUC-KR and all aliases for it unmatchable, thereby making the vulnerable code unreachable.

On Thu, Feb 13, 2025 at 12:15:54PM -0500, Rich Felker wrote: Vulnerability description:

A vulnerability has been identified in musl libc's implementation of iconv that can result in out-of-bounds memory writes in applications which process untrusted input using iconv and where the input charset for the conversion is input-controlled.

In order for the vulnerability to be exposed, an application must call iconvopen with an output encoding of UTF-8 and and input encoding of EUC-KR, and must subsequently process untrusted input using the resulting conversion descriptor. The most common scenario in which this occurs is using the declared MIME charset of untrusted input (for example, in XML, HTML, or MIME-encoded email) as input to iconvopen for converting arbitrary-encoding input to UTF-8.

This issue was discovered and reported by Nick Wellnhofer. It arose as a combination of incorrect input byte validation in the EUC-KR decoder, and the fact that the UTF-8 output encoder assumed an invariant that the input decoder never produces character codes which are not valid Unicode Scalar Values. Addendum: I also have a test program that will check if your iconv is affected, attached. It runs over all 65536 byte pairs and looks for bogus changes to the output buffer pointer/remaining.

musl libc 0.9.13 through 1.2.5 before 1.2.6 has an out-of-bounds write vulnerability when an attacker can trigger iconv conversion of untrusted EUC-KR text to UTF-8.

Vulnerability description:

A vulnerability has been identified in musl libc's implementation of iconv that can result in out-of-bounds memory writes in applications which process untrusted input using iconv and where the input charset for the conversion is input-controlled.

In order for the vulnerability to be exposed, an application must call iconvopen with an output encoding of UTF-8 and and input encoding of EUC-KR, and must subsequently process untrusted input using the resulting conversion descriptor. The most common scenario in which this occurs is using the declared MIME charset of untrusted input (for example, in XML, HTML, or MIME-encoded email) as input to iconvopen for converting arbitrary-encoding input to UTF-8.

This issue was discovered and reported by Nick Wellnhofer. It arose as a combination of incorrect input byte validation in the EUC-KR decoder, and the fact that the UTF-8 output encoder assumed an invariant that the input decoder never produces character codes which are not valid Unicode Scalar Values.

Affected versions:

The vulnerable code has been present since EUC-KR support was added to iconv in musl 0.9.13. All versions in the range 0.9.13 through 1.2.5 are affected.

Future releases beginning with 1.2.6 will ship with the bug fixed.

Mitigation:

All users should apply the source patches included/attached below. The first fixes the bug (incorrect input byte validation) responsible for the vulnerability, and the second closes off the vector by which this class of bug escalated to an out-of-bounds write. These patches should apply cleanly to all versions affected by the bug.

Users of musl libc based distributions should obtain an updated package with the patch applied through their distributon's update channels.

Static-linked binaries that cannot easily be relinked may be patched to inhibit the vulnerability, at the cost of disabling support for decoding EUC-KR text, by searching the binary, using a binary-clean/hex editor, for the byte sequence:

"euckr\0ksc5601\0ksx1001\0cp949\0"

and replacing it with:

"-----\0-------\0-------\0-----\0"

Since non-alphanumeric-ASCII characters are stripped from the charset name by iconvopen, this change will render EUC-KR and all aliases for it unmatchable, thereby making the vulnerable code unreachable.