CVE-2026-77117: SHIFT_JISX0213 decoding may hang on crafted input
Converting crafted SHIFTJISX0213 input to UCS-4 or the internal wide character encoding, for example with iconv, in the GNU C Library version 2.3 to 2.44 may result in the converter making no progress, causing the calling application to hang.
Some SHIFTJISX0213 sequences decode to two code points. If the output buffer has room for only the first one, the converter stores the second in the conversion state and returns E2BIG, but it never clears that pending character after emitting it on the next call. The converter then keeps emitting the pending character without consuming further input, so an application that retries the conversion loops forever. The input must be attacker controlled and the application must convert it with an output buffer small enough to split the two code points. Only the SHIFTJISX0213 character set is affected, which is not commonly used. The related defect in the EUCJISX0213 converter is tracked separately as CVE-2026-80489.
Other sources
SHIFTJISX0213 decoding may hang on crafted input
— Microsoft
Summary: Non-progress DoS in SHIFTJISX0213 -> UCS-4 conversion state <br/> handling (iconvdata/shiftjisx0213.c): crafted input can cause repeated <br/> emission of a buffered code point without further input consumption, <br/> leading to persistent retry churn and denial of service in callers <br/> converting untrusted text.<br/> Requirements to exploit: An attacker must be able to supply text that an <br/> application converts from SHIFTJISX0213 to UCS-4, trigger a 2-byte <br/> sequence that expands through jisx0213toucscombining, and have the <br/> caller retry after E2BIG with the same conversion state once only enough <br/> output space remains for the first of the two emitted code points. <br/> Applications that never use this conversion path, or that abort on repeated <br/> no-progress E2BIG, are not practically exposed.<br/> Component affected: glibc-2.42-11.1.hum1; iconvdata/shiftjisx0213.c, <br/> fromshiftjisx0213 (BODY macro) in the SHIFTJISX0213 -> UCS-4 <br/> conversion path.<br/>
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/glibcto a version that resolves this vulnerability.Fixed in 2.43-5
Event History
Frequently Asked Questions
Which applications are practically exposed to this denial of service?
Applications are practically exposed only if they convert attacker-controlled text from SHIFT_JISX0213 to UCS-4. Callers that retry after E2BIG using the same conversion state, rather than detecting repeated no-progress failures, are the relevant risk case.
What input and runtime conditions are required to trigger the issue?
The attacker must provide a 2-byte sequence that expands through __jisx0213_to_ucs_combining. The caller must then retry after E2BIG with output space sufficient for only the first of the two code points emitted from the buffered state.
Are applications that use glibc iconv generally affected?
No. Applications that do not use the SHIFT_JISX0213 to UCS-4 conversion path are not practically exposed, and applications that abort when E2BIG repeats without conversion progress are also not practically exposed.
What mitigation is available if updating the affected component is not immediately possible?
Ensure conversion callers detect repeated E2BIG results with no input consumption or output progress and abort rather than retrying indefinitely. Avoid processing untrusted input through the SHIFT_JISX0213 to UCS-4 conversion path where feasible.