DF-3124 — cd9660 kiconv mount: ignored iconv_open() failure → convchr(NULL) kernel panic

What

iso_mountfs() (sys/vfs/isofs/cd9660/cd9660_vfsops.c:491-499) ignores the return value of both cd9660_iconv->open() calls. When the charset pair cannot be opened (empty, unregistered, or unavailable charset names — iconv_open() returns ENOENT), isomp->im_d2l / isomp->im_l2d stay NULL while im_flags still carries ISOFSMNT_KICONV. The first pathname lookup or readdir on the mount then does:

namei -> cd9660_lookup -> isofncmp(..., imp->im_l2d) -> sgetrune()
      -> cd9660_iconv->convchr(NULL, ...)          (cd9660_util.c sgetrune)
      -> iconv_convchr(NULL) -> KOBJ dispatch reads ops through NULL
      -> kernel page fault at VA 0 -> panic

cd9660_unmount() (cd9660_vfsops.c:584-589) already NULL-checks both handles before close — the NULL state is clearly anticipated; the consumers were simply never made safe against it.

Reproduce (on the QEMU guest, as root)

# 1. stage files (from the pack): poc.iso (minimal crafted ISO9660 image),
#    trigger.c
scp poc.iso trigger.c dfbsd:/root/

# 2. in the guest:
vnconfig -c -S 2048 /dev/vn0 /root/poc.iso
kldload libiconv
kldload cd9660_iconv
cc -O -o /root/trigger /root/trigger.c -I/usr/src/sys
mkdir -p /mnt/poc
/root/trigger          # mounts with ISOFSMNT_KICONV + empty charsets, then stat()s

Expected

[+] mount succeeded with ISOFSMNT_KICONV and failed iconv_open (im_d2l == im_l2d == NULL)
[+] triggering namei under the mount ...

…then the console shows:

Fatal user address access from kernel mode from trigger at ...
Fatal trap 12: page fault while in kernel mode
fault virtual address    = 0x0
Stopped at      iconv_convchr+0x27:     movq    (%rdi),%rsi

Baseline

The same image mounted without -o kiconv (mount_cd9660 /dev/vn0 /mnt/poc) mounts cleanly; lookups return ENOENT; unmount works. The panic is specific to the KICONV flag with a failed charset open.

Impact

NULL-deref kernel panic (local DoS). The deref target is fixed address 0 — no control over the faulting pointer, no escalation primitive. Mounting requires root / SYSCAP_RESTRICTEDROOT (get_fscap("cd9660")), but the panic trigger is any namei under the mount, i.e. any local user after an admin has made such a mount.

DF-3124 — VERDICT

Status: reproduced (impact: panic — NULL-deref local DoS; confidence: certain) Reproduced twice, each time from a fresh vm.sh reset with-src boot: deterministic.

Root cause (line-accurate)

• sys/vfs/isofs/cd9660/cd9660_vfsops.c:494 — cd9660_iconv->open(cs_local, cs_disk, &isomp->im_d2l); — return value ignored.
• sys/vfs/isofs/cd9660/cd9660_vfsops.c:495 — same for im_l2d.
• On failure both handles stay NULL (isomp is M_ZERO-allocated, line 412) while im_flags keeps ISOFSMNT_KICONV (masked in at line 486-489).
• Consumers pass the raw handle to the KOBJ dispatcher:
• sys/vfs/isofs/cd9660/cd9660_util.c sgetrune() — cd9660_iconv->convchr(handle, ...) guarded only by flags & ISOFSMNT_KICONV && cd9660_iconv (module pointer), NOT by handle != NULL. Reached from every non-'.'/non-'..' name comparison: cd9660_lookup.c:237-238 (isofncmp(..., imp->im_d2l, imp->im_l2d)).
• cd9660_util.c isochar() — same pattern, reached on Joliet mounts (readdir via isofntrans).
• iconv_convchr() (sys/libiconv/iconv.c:290-294) dispatches through the handle as a kobj → movq (%rdi),%rsi at address 0 → page fault → panic.
• cd9660_unmount() (cd9660_vfsops.c:584-589) NULL-checks both handles before close() — proving NULL handles are an anticipated state that the consume paths don't defend against.

Why iconv_open fails in practice

mount_cd9660 -o kiconv (sbin/mount_cd9660) sets the flag without ever registering a charset pair (set_charset() is only called for -C), leaving cs_local/cs_disk as empty strings; iconv_open("","") finds no registered cspair (and no converter modules) → ENOENT, silently ignored. Any direct mount(2) caller (this PoC) hits the same path. A successful -C registration that later becomes unavailable (module unload — see DF-2233) reaches the same NULL-handle state at lookup time.

Reproduction narrative

1. Host: crafted a 40-sector minimal ISO9660 image (Python; PVD at sector 16 with root directory record → extent 18, terminator at 17, "."/".." records at 18). No Joliet SVD needed — the panic goes through sgetrune().
2. Guest: vnconfig -c -S 2048 /dev/vn0, kldload libiconv, kldload cd9660_iconv, compile trigger.c (cc -O -I/usr/src/sys).
3. Baseline: mount_cd9660 /dev/vn0 /mnt/poc (no kiconv) — mounts, stat /mnt/poc/a → ENOENT, clean unmount. Image is valid.
4. Trigger: /root/trigger — mount(2) with ISOFSMNT_KICONV and zeroed cs_local/cs_disk; mount succeeds (open failures ignored); stat("/mnt/poc/a") → guest panics instantly: Fatal user address access from kernel mode from trigger at ffffffff82600bb7 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 instruction pointer = 0x8:0xffffffff82600bb7 (inside libiconv.ko) current process = 914 (trigger) Stopped at iconv_convchr+0x27: movq (%rdi),%rsi
5. Re-ran from a fresh reset: identical panic (pid 869). Deterministic.

Exploit chain

None. The faulting address is a fixed NULL (the KOBJ ops load); there is no attacker influence over the dereferenced pointer, no write primitive. This is a denial-of-service bug, not an escalation. (Checked: handle is used purely as *(kobj_t) for method dispatch — no partial control path.)

Reachability / gating

• Mounting cd9660 requires root-equivalent privilege (get_fscap("cd9660") == SYSCAP_RESTRICTEDROOT, sys/kern/vfs_syscalls.c:5383-5398 — even with vfs.usermount=1).
• After such a mount exists, ANY local user triggers the panic with a plain stat()/ls under the mountpoint.
• Severity: Low (privileged mount-time opt-in with a broken charset; unprivileged post-mount DoS).

Fix

fix.diff — check both open() returns; on any failure close the half-opened handle, NULL both, and clear ISOFSMNT_KICONV so isochar()/sgetrune() take their non-iconv fallback (identical discipline to the existing cd9660_iconv == NULL path). Also forces NUL-termination of the copied charset names (adjacent hardening, cf. DF-0854 in msdosfs).

Fix validation: not_testable by choice — this is a Low-severity NULL-deref DoS; per the audit's conditional-verification policy the kernel-rebuild fix-validation cycle is reserved for Critical/High and memcorrupt/privesc findings. The fix is a guarded fallback that mirrors logic already present in cd9660_unmount().

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.