{
 "finding_id": "DF-3130",
 "status": "not_reproduced",
 "reproduced": 0,
 "impact": "leak",
 "confidence": "certain",
 "verdict": "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.",
 "exploit_chain": "",
 "evidence": "run.log (40+200 remount attempts, ENOENT, 1187 update_mp prints, iconv counters flat), remount_leak.c (uses the real <vfs/msdosfs/msdosfsmount.h> struct)",
 "kernel_refs": [
  "sys/vfs/msdosfs/msdosfs_vfsops.c:115-133",
  "sys/vfs/msdosfs/msdosfs_vfsops.c:258-279"
 ],
 "poc_changes": "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)",
 "attempts": 4,
 "guest_uname": "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",
 "runtime_sec": 300,
 "guest_dirty": 0,
 "build_cmd": "guest: cc -O -lkiconv -o remount_leak remount_leak.c",
 "run_cmd": "guest: mount_msdos -o ro -L zh_CN.GB18030 -D GB18030 /dev/vn0 /mnt && ./remount_leak /dev/vn0 /mnt 40",
 "code_hash": "4832cb792f51248f91390cc19790aa749c08d034b64163ed06394da9637898d0",
 "notes": "",
 "recommended_fix": "close existing handles before re-opening"
}