CVE-2026-57053

An attacker supplies a crafted domain name to an application that normalizes input using the Libidn ToUnicode API (e.g. `idna_to_unicode_8z8z()`). The attacker includes a label such as `xn--com-` that decodes to a short ASCII string like `com`. Because `tmpout + 4` points into the uninitialized tail of the stack buffer, the round-trip comparison may match on stale stack bytes, causing the invalid ACE label to be silently normalized to `com`, `net`, `www`, etc. [CWE-457]. The effect can also carry across separate API calls if earlier labels leave matching bytes on the stack. The victim application may then use the incorrectly normalized hostname for allowlists, blocklists, routing, or logging decisions.

The bug resides in `idna_to_unicode_internal()` in `lib/idna.c`. The function decodes a Punycode label, calls `idna_to_ascii_4i()` into a local stack buffer `tmpout[64]`, then compares the original label against `tmpout + strlen(IDNA_ACE_PREFIX)` assuming the ToASCII result always begins with `xn--`. When the decoded label is pure ASCII, the ToASCII routine leaves it unchanged, so a short ASCII label (fewer than 4 characters) causes the comparison to read stale stack bytes past the initialized string.

The patch [patch_id=7163099] implements the fix suggested in the initial report [ref_id=1]. It adds a check that the ToASCII result actually begins with the ACE prefix before comparing the suffix: if `tmpout` does not start with `xn--`, the function returns `IDNA_ROUNDTRIP_VERIFY_ERROR` immediately. This prevents reading past the initialized portion of `tmpout` when the decoded label is all ASCII and therefore unchanged by ToASCII. The advisory [ref_id=2] recommends upgrading to libidn 1.44 or applying the patch.