KICONV mounts: invalid-charset input yields 0-rune without consuming input, so isofncmp returns 0 (match) for non-equal names
Summary
When cd9660 is mounted with -C (KICONV + cd9660_iconv.ko), an input byte sequence absent from the conversion table makes iconv_xlat16_conv fail having consumed ZERO bytes and written zero output. Consequences: sgetrune (:206-215) computes len=consumed=0, so c is 0 while fn is NOT advanced; isochar's kiconv branch yields c=0/clen=0 while consuming 2 image bytes. In isofncmp, when the image name is exhausted before the user name, :112-113 executes 'return d' with d==0 - an exact match - so stat/open of 'FOO\x80' matches an image entry named 'FOO'. Restricted to KICONV mounts (deliberate root config, or usermount once modules loaded). Same honest ceiling: RO ACL-less fs, no permission differential, no memory-safety impact, no infinite loop. Fix: treat zero-consumption convchr as EILSEQ (consume 1 byte, return it) + defensive non-zero return in isofncmp. [VERIFIED pass2: zero-consumed invalid rune false-match mechanism confirmed; KICONV mount plumbing broken per DF-3124 so demo would test that other bug; consume-one fix compiled]
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-3247 · 4 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 239 B | ↓ raw | |
| fix.diff | — | 1.2 KB | view raw | |
| manifest.json | — | 372 B | view raw | |
| verdict.json | — | 1.8 KB | view raw |
DF-3247 evidence pack
What
KICONV: zero-consumed invalid runes make isofncmp return 0 (match)
Verdict
status=not_reproduced impact=none confidence=certain
See VERDICT.md for the full narrative and fix.diff for the verified fix.
Fix verification
not_testablefix.diff applied in the F40FIX verification kernel build (RC=0, zero -Werror errors); no runtime A/B for this item (line-certain hardening)
Confirmed kernel references
Detail
Evidence (decisive lines)
VERDICT.md with path:line citations; run.log where a live demo exists; fix.diff
PoC changes
n/a - KICONV mount path unavailable on this guest (see DF-3124)
Verified recommended fix
sgetrune: when convchr consumes nothing, consume one raw byte instead of returning a stale c=0
Verdict
Line-accurate confirmation; runtime demonstration not attempted (requires a cd9660 -C KICONV mount with cd9660_iconv.ko and a high-byte filename; the DF-3124 rig on this guest showed the KICONV mount plumbing is itself broken - iconv_open of the empty pair fails - so the demonstration would test that other bug instead). Mechanism confirmed from source: on an input sequence absent from the conversion table, convchr consumes ZERO bytes and writes zero output, so sgetrune computes len=consumed=0, returns c=0 and does NOT advance fn (cd9660_util.c:206-215); when the image name is exhausted first, isofncmp hits return d with d==0 at :112-113 - an exact match for a non-equal name. Fix: on zero consumption fall back to consuming one raw byte (no false match); compiled in the F40FIX build.
No comments yet.