# DF-3130 verification

Kernel: DragonFly dfbsd 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64

## Bottom line

The leak is code-certain (update_mp re-opens all four iconv handles on every MNT_UPDATE with fspec and overwrites pm_w2u/pm_u2w/pm_u2d/pm_d2u without closing, and pm_flags keeps MSDOSFSMNT_KICONV sticky so even KICONV-less updates re-open) and the path is confirmed live: 1187 kernel update_mp prints during the attempt loop. But on this guest every re-open of the previously-registered pairs fails with ENOENT inside kernel libiconv when invoked from a raw mount(2) MNT_UPDATE (the CLI pre-registers conversion tables via kiconv(3) at initial mount and no CLI path expresses a kiconv remount), so no handle churn occurs to observe and the vmstat -m iconv counters stay flat. Attempt harness and full logs retained; fix compile-validated.

## Kernel references
- sys/vfs/msdosfs/msdosfs_vfsops.c:115-133
- sys/vfs/msdosfs/msdosfs_vfsops.c:258-279

## Exploit chain
(none: availability/correctness finding; no privilege chain)

## Fix

close existing handles before re-opening

See fix.diff in this directory (git-apply-able against the read-only sys/
tree; applied only inside the disposable verification guest).

## Reproduction

build: guest: cc -O -lkiconv -o remount_leak remount_leak.c

run: guest: mount_msdos -o ro -L zh_CN.GB18030 -D GB18030 /dev/vn0 /mnt && ./remount_leak /dev/vn0 /mnt 40

expected: code path reached (kernel prints local/dos per attempt); on this guest each re-open fails ENOENT in kernel libiconv so no leak is observable

## Notes on the PoC (what changed vs the finding sketch)

three iterations: struct msdosfs_args must come from <vfs/msdosfs/msdosfsmount.h> (hand-rolled export_args ABI-mismatches), DFly mount(2) takes the fstype as first argument, and the kiconv(3) pair registration returns EINVAL for an already-registered pair so it was dropped (pm_flags is sticky)

## 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.