Some SHIFT_JISX0213 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 SHIFT_JISX0213 character set is affected, which is not commonly used. The related defect in the EUC_JISX0213 converter is tracked separately as CVE-2026-80489.
Analysis and contextual insights are available on OpenCVE Cloud.
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
| Source | ID | Title |
|---|---|---|
Ubuntu USN |
USN-8737-1 | GNU C Library vulnerabilities |
Ubuntu USN |
USN-8737-2 | GNU C Library vulnerabilities |
Tue, 15 Sep 2026 13:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Tue, 15 Sep 2026 11:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | A flaw was found in glibc. A remote attacker could exploit this vulnerability by providing specially crafted input during SHIFT_JISX0213 to UCS-4 text conversion. This crafted input can cause the application to repeatedly emit a buffered code point without consuming further input, leading to persistent retry churn. This can result in a denial of service (DoS) for callers converting untrusted text. | Converting crafted SHIFT_JISX0213 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 SHIFT_JISX0213 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 SHIFT_JISX0213 character set is affected, which is not commonly used. The related defect in the EUC_JISX0213 converter is tracked separately as CVE-2026-80489. |
| Title | glibc: Non-progress DoS in SHIFT_JISX0213 -> | SHIFT_JISX0213 decoding may hang on crafted input |
| References |
|
Mon, 31 Aug 2026 21:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Gnu
Gnu glibc |
|
| Vendors & Products |
Gnu
Gnu glibc |
Tue, 25 Aug 2026 12:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | A flaw was found in glibc. A remote attacker could exploit this vulnerability by providing specially crafted input during SHIFT_JISX0213 to UCS-4 text conversion. This crafted input can cause the application to repeatedly emit a buffered code point without consuming further input, leading to persistent retry churn. This can result in a denial of service (DoS) for callers converting untrusted text. | |
| Title | glibc: Non-progress DoS in SHIFT_JISX0213 -> | |
| Weaknesses | CWE-835 | |
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Status: PUBLISHED
Assigner: glibc
Published:
Updated: 2026-09-15T12:26:33.285Z
Reserved: 2026-08-20T12:24:17.417Z
Link: CVE-2026-77117
Updated: 2026-09-15T12:26:27.547Z
Status : Received
Published: 2026-09-15T11:17:12.063
Modified: 2026-09-15T13:16:43.340
Link: CVE-2026-77117
OpenCVE Enrichment
Updated: 2026-09-16T05:45:16Z
Ubuntu USN