[pbrowne011]

It seems crazy to me that vulnerabilities like this still exist today. I understand that not everything will be written in Rust, but this could have been caught by basic testing and/or fuzzing, as Nick (the person who found the vulnerability) points out: https://www.openwall.com/lists/musl/2025/02/14/1. So far, this earned an 8.1 from MITRE: https://nvd.nist.gov/vuln/detail/CVE-2025-26519, although I'm not sure if that's just a function of it being a bug in a library that so many applications use.

This also goes to show how every line matters. The one line change was from

    if (c >= 93 || c>=0xc6-0x81 && d>0x52)

to

    if (c > 0xc6-0x81 || c==0xc6-0x81 && d>0x52)

Link to relevant source code: https://git.musl-libc.org/cgit/musl/tree/src/locale/iconv.c (bug fix is line 505).

To explain the bug, EUC_KR is Extended Unicode - Korean. After ASCII characters (0-127), each character is multiple bytes. The logic adjusts to look up from a base-0 index, then checks that both bytes (variables c and d) are in the normalized range. If not, the code adjusts the characters and checks the bounds again. This second check is what contained the bug.

0xc6 - 0x81 is the upper bound of this check (69), not 93. The irony is that the second part of the check gets this correct. I wonder what a `git blame` would reveal about this particular line.