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.

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).

[Unknown description]

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.

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.

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 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.

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

========================================== 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 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

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

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;

CVE-2026-107891: musl libc: multiple integer overflow in regcomp, possibly leading to incorrect allocation sizes and out-of-bounds heap writes

Overview:

The regcomp function in musl libc is affected by multiple integer overflow issues which can lead to incorrectly-sized allocations and possibly out-of-bounds heap writes. The conditions for overflow are triggered by the size and complexity of the regular expression passed to regcomp, not the data to be matched. In order to be vulnerable, an application must be processing regular expressions from an untrusted source using the libc regcomp function.

Impact:

At least denial-of-service in the form of a predictable crash is possible. Depending on the application and its use of objects on the heap and of concurrent execution, arbitrary code execution may be possible.

Affected versions:

The vulnerable code has been present since version 0.5.0.

All subsequent versions up through 1.2.6 are affected.

Mitigation:

All users should apply the attached patch, or upgrade to 1.2.7 once it becomes available.

In contexts where patching is not an option, measures should be taken to prevent the processing of regular expressions from untrusted sources.

Credits:

The first of these issues was reported in private by Julien Voisin. Subsequent analysis by Szabolcs Nagy and Rich Felker found a pattern of similar overflows.

OpenSSH just published OpenSSH 10.6p2 with a critical fix for a password authentication bypass on systems that use musl libc and have PAM disabled. Alpine Linux has been called out as one such affected system:

https://www.openssh.org/releasenotes.html#10.6p2 sshd(8): avoid password authentication bypass that is exploitable through sshd(8) that affects some Linux systems when built and run with PAM support disabled. We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there.

This bug was reported by Özgün Kültekin of Wakefield (wakefield.co) The vulnerability itself is described here:

https://sshhole.com/

(The history of how we got here is actually fun.)

That is, for any account that has an invalid password hash field of '', you can log in by entering a password >257 characters, which will cause crypt(3) in musl libc to return ''.

The code fix (checking for MINPASSWORDHASHLEN instead of using musl crypt(3)'s default "") is here: https://github.com/openssh/openssh-portable/commit/4353fdc43ef646c43a8dda7025cc1a898caf1482

Setting PasswordAuthentication no in /etc/ssh/sshdconfig mitigates the problem (at the obvious cost of not being able to do password auth).

On Thu, 5 Nov 2026 at 23:14, Jan Schaumann <jschauma () netmeister org> wrote: OpenSSH just published OpenSSH 10.6p2 with a critical fix for a password authentication bypass on systems that use musl libc and have PAM disabled. Alpine Linux has been called out as one such affected system:

https://www.openssh.org/releasenotes.html#10.6p2 sshd(8): avoid password authentication bypass that is exploitable through sshd(8) that affects some Linux systems when built and run with PAM support disabled. We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there.

This bug was reported by Özgün Kültekin of Wakefield (wakefield.co) The vulnerability itself is described here:

https://sshhole.com/ It's unfortunate that some people are writing misleading statements about a security problem in OpenSSH, especially on linkedin, despite djm@ explaining that this is a WORKAROUND.

On 2026-11-05 23:38:51 +0400, Loganaden Velvindron wrote: It's unfortunate that some people are writing misleading statements about a security problem in OpenSSH, especially on linkedin, despite djm@ explaining that this is a WORKAROUND. This is not clear. Under Debian, the crypt(3) man page says:

Upon error, cryptr, cryptrn, and cryptra write an invalid hash to the output field of their data argument, and crypt writes an invalid hash to its static storage area. This string will be shorter than 13 characters, will begin with a ‘’, and will not compare equal to setting.

So it seems that "" could be a valid result in case of error.

-- Vincent Lefèvre <vincent () vinc17 net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

Upon error, cryptr, cryptrn, and cryptra write an invalid hash to the output field of their data argument, and crypt writes an If an error string is output does not : or multiple :: better express the aim of never seeing this as field content (because it is field separator) ?

On 2026-11-05 23:10:52 +0000, lists () notatla org uk wrote: Upon error, cryptr, cryptrn, and cryptra write an invalid hash to the output field of their data argument, and crypt writes an If an error string is output does not : or multiple :: better express the aim of never seeing this as field content (because it is field separator) ? Perhaps, but in any case, it is up to the application to check error conditions, in particular that the result contains only valid characters.

-- Vincent Lefèvre <vincent () vinc17 net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

On 2026-11-05 23:50:00, Vincent Lefevre wrote: This is not clear. Under Debian, the crypt(3) man page says... So it seems that "" could be a valid result in case of error. The PORTABILITY NOTES go on to say,

The behavior of crypt on errors isn't well standardized. Some implementations simply can't fail (except by crashing the program), others return a null pointer or a fixed string. Most implementations don't set errno, but some do. POSIX specifies returning a null pointer and setting errno, but it defines only one possible error, ENOSYS, in the case where crypt is not supported at all. Some older applications are not prepared to handle null pointers returned by crypt. The behavior described above for this implementation, setting errno and returning an invalid hash different from setting, is chosen to make these applications fail closed when an error occurs.

The linux man-pages have a glibc bias, but of course musl has no documentation at all. If you turn to POSIX for help, it's vague to the point of being useless, and somehow still manages to mischaracterize the status quo. Having tried to portably accomodate crypt(3), iconv(3), and the gettext(3) family recently, this situation is more common than you might think. In the end I gave up on crypt(3) entirely, as the musl implementation in Gentoo is easy to replace with libxcrypt's. Of course, libxcrypt ALSO uses "failure tokens" if you are not careful to disable them.

Anyway, my point is, no one knows what the output from crypt(3) will be, so doing a strcmp on it to authenticate logins is... optimistic.

On Thu, Nov 05, 2026 at 11:50:00PM +0100, Vincent Lefevre wrote: On 2026-11-05 23:38:51 +0400, Loganaden Velvindron wrote: It's unfortunate that some people are writing misleading statements about a security problem in OpenSSH, especially on linkedin, despite djm@ explaining that this is a WORKAROUND. This is not clear. Under Debian, the crypt(3) man page says:

Upon error, cryptr, cryptrn, and cryptra write an invalid hash to the output field of their data argument, and crypt writes an invalid hash to its static storage area. This string will be shorter than 13 characters, will begin with a ‘’, and will not compare equal to setting.

So it seems that "" could be a valid result in case of error. Prior to ~2019 when the OpenSSH change was made, Debian would have shown a different manpage that only documents NULL for error [1]. Changing system APIs is problematic!

https://www.man7.org/linux/man-pages/man3/crypt.3.html#RETURNVALUE

On success, a pointer to the hashed password is returned. On error, NULL is returned.

Cheers, Matt

[1] https://salsa.debian.org/debian/manpages/-/commit/c56791e95a0759d58ded54150466f207c7cf3322 The current manpage comes from libxcrypt (libcrypt-dev package) rather than manpages-dev package.

On Thu, Nov 5, 2026 at 2:15 PM Jan Schaumann <jschauma () netmeister org> wrote: OpenSSH just published OpenSSH 10.6p2 with a critical fix for a password authentication bypass on systems that use musl libc and have PAM disabled. Alpine Linux has been called out as one such affected system:

https://www.openssh.org/releasenotes.html#10.6p2 sshd(8): avoid password authentication bypass that is exploitable through sshd(8) that affects some Linux systems when built and run with PAM support disabled. We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there.

This bug was reported by Özgün Kültekin of Wakefield (wakefield.co) The vulnerability itself is described here:

https://sshhole.com/

(The history of how we got here is actually fun.)

That is, for any account that has an invalid password hash field of '', you can log in by entering a password >257 characters, which will cause crypt(3) in musl libc to return ''.

The code fix (checking for MINPASSWORDHASHLEN instead of using musl crypt(3)'s default "") is here: https://github.com/openssh/openssh-portable/commit/4353fdc43ef646c43a8dda7025cc1a898caf1482

Setting PasswordAuthentication no in /etc/ssh/sshdconfig mitigates the problem (at the obvious cost of not being able to do password auth). One general comment that does not fit well into most of the discussions around sshole... The practice of using a single character "", or a shorter string of random characters so hashes do not match, likely provides the conditions for a side channel or timing attack. Usually, the crypto routines should be near-constant time as possible. Short-circuiting due to mismatched string lengths certainly provides the side channel.

Whether the side-channel provides for an actual vulnerability is another discussion.

[] With lots of hand-waiving about what it means to be constant time or near-constant time on modern cpu architectures.

Jeff

On 2026-11-06 10:05:13 +0800, Matt Johnston wrote: On Thu, Nov 05, 2026 at 11:50:00PM +0100, Vincent Lefevre wrote: This is not clear. Under Debian, the crypt(3) man page says:

Upon error, cryptr, cryptrn, and cryptra write an invalid hash to the output field of their data argument, and crypt writes an invalid hash to its static storage area. This string will be shorter than 13 characters, will begin with a ‘’, and will not compare equal to setting.

So it seems that "" could be a valid result in case of error. Prior to ~2019 when the OpenSSH change was made, Debian would have shown a different manpage that only documents NULL for error [1]. Changing system APIs is problematic!

https://www.man7.org/linux/man-pages/man3/crypt.3.html#RETURNVALUE

On success, a pointer to the hashed password is returned. On error, NULL is returned. But note that https://www.man7.org/linux/man-pages/man3/crypt.3.html#DESCRIPTION also specifies:

salt is a two-character string chosen from the set [a-zA-Z0-9./].

with an EINVAL error in this case.

And according to <https://sshhole.com/>, the $ character is used in salt. So this usage is out of scope of the spec (and the man page was apparently obsolete, because an error would have always been expected with a $ in salt).

POSIX.1-2008 (referenced by the above man page), and still in the 2024 edition, is even stricter, with a "shall":

The salt argument shall be a string of at least two bytes in length not including the null character chosen from the set: [same set]

https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/crypt.html https://pubs.opengroup.org/onlinepubs/9799919799/functions/crypt.html

(An implementation could specify what happens when other characters are used, but other implementations may behave differently.)

-- Vincent Lefèvre <vincent () vinc17 net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

Jeffrey Walton <noloader () gmail com> writes: One general comment that does not fit well into most of the discussions around sshole... Another contributing factor, "sshd borrows bob's salt" and the derived changes, was the quaint 1970s notion that no-one would ever be able to guess that there exist account names like root, daemon, ldap, postfix, apache, mysql, sshd, and rumpelstiltskin, so we'll add a kludge to make invalid accounts take the same time as valid ones. Attackers don't even notice this because they start with a pregenerated list of known and probable accounts, but it does help to add vulnerabilities to the password-checking process as this CVE shows.

Peter.

Martin Steigerwald wrote in <lAcUgmfSTD6YfF29yvDOHQ () lichtvoll de>: |Greetings. | |Matt Johnston - 06.11.26, 03:05:13 CET: |> Prior to ~2019 when the OpenSSH change was made, Debian |> would have shown a different manpage that only documents |> NULL for error [1]. |> Changing system APIs is problematic! | |That. | |If applications do not check for a NULL pointer: | |Let them crash! | |Really.

Yet this all is SysV / BSD a.k.a. UNIX.

#?0|lecce:ucb-csrg-bsd$ git lo master -- lib/libc/gen/crypt.c | tail -n1 701ef780846a72969d45e56612122f4c8a0ddb47 date and time created 80/12/21 16:39:32 by wnj

#?0|lecce:unix-hist$ git grep -F 'crypt(' Research-V3 | head -n1 Research-V3:man/man0/index: crypt(III): encrypt according to a keyword

#?0|lecce:unix-hist$ gl1 Research-V3 | grep ^Commit Commit: Ken Thompson <ken () research uucp> CommitDate: 1973-08-30 19:34:53 -0500

POSIX example does not test for NULL.

...

--steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

Greetings.

Matt Johnston - 06.11.26, 03:05:13 CET: Prior to ~2019 when the OpenSSH change was made, Debian would have shown a different manpage that only documents NULL for error [1]. Changing system APIs is problematic! That.

If applications do not check for a NULL pointer:

Let them crash!

Really.

Am I the only one thinking that the work-around in OpenSSH will not be enough to truly address this issue? Do we really know whether this behavior can not cause security havoc anywhere else?

The work-around in OpenSSH is important. Thanks!

But is it sufficient? https://www.man7.org/linux/man-pages/man3/crypt.3.html#RETURNVALUE

On success, a pointer to the hashed password is returned. On error, NULL is returned. Best, -- Martin

I've done some auditing of crypt() usage in the Linux ecosystem. Most software is now handling NULL from crypt() but there are some issues like https://github.com/InfrastructureServices/vsftpd/pull/9

I think it's time for musl libc to revisit the idea and return NULL on failure and see which software is still breaking.

The commit in musl dates back to 2012. A lot has happened since 2012: https://git.musl-libc.org/cgit/musl/commit/?id=b3c4cc121f70faea45389fe7ddc1127ed5cbd8bb

On 2026-11-06 23:57:43, Loganaden Velvindron wrote: I think it's time for musl libc to revisit the idea and return NULL on failure and see which software is still breaking. It was easy to lose in the noise, but musl is not the only one doing this:

https://github.com/besser82/libxcrypt/blob/develop/configure.ac#L322