CVE-2026-35373

In target-directory forms (`ln SOURCE... DIRECTORY`), `ln` rejects source paths with non-UTF-8 filename bytes, while GNU accepts them. Breaks GNU compatibility for byte-oriented filenames on Unix filesystems. PoC: ``` name=$(printf 'bad_\377'); mkdir dst; : > "$name"; ln "$name" dst # GNU: exit 0, creates dst/bad_\377 ; uutils: exit 1, dst empty ``` --- _Zellic private finding (zellic-ext/coreutils-private PR #84). Reported in the Zellic *uutils coreutils Program Security Assessment* (for Canonical, Jan 2026), audited commit `3a07ffc5a9bd4c283e75afa548ba1f1957bad242`._

### Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-jcjr-rh8q-7xqf. This link is maintained to preserve external references. ### Original Description A logic error in the ln utility of uutils coreutils causes the program to reject source paths containing non-UTF-8 filename bytes when using target-directory forms (e.g., ln SOURCE... DIRECTORY). While GNU ln treats filenames as raw bytes and creates the links correctly, the uutils implementation enforces UTF-8 encoding, resulting in a failure to stat the file and a non-zero exit code. In environments where automated scripts or system tasks process valid but non-UTF-8 filenames common on Unix filesystems, this divergence causes the utility to fail, leading to a local denial of service for those specific operations.