{
 "finding_id": "DF-3113",
 "status": "not_reproduced",
 "reproduced": 0,
 "impact": "denial_of_service",
 "confidence": "certain",
 "verdict": "Code-proven, production-only. Both hammer_ioc_add_snapshot and hammer_ioc_del_snapshot take hmp->snapshot_lock exclusively and return directly from the hammer_init_cursor failure path without unlocking (unlike their success paths). On the stock INVARIANTS guest the same failure hits the hammer_cursor.c:202 KKASSERT first and panics (demonstrated live for the shared trigger in the DF-3109 pack), so the lock leak cannot manifest on this kernel; on production builds every subsequent snapshot ioctl and hammer cleanup blocks forever on the leaked exclusive lock. Fix adds the unlock to both error paths; compile-validated in the combined build.",
 "exploit_chain": "",
 "evidence": "VERDICT.md source walk at hammer_ioctl.c:727-737 and :804-814; the shared init-cursor failure trigger is live-demonstrated in findings/poc/DF-3109/panic.txt",
 "kernel_refs": [
  "sys/vfs/hammer/hammer_ioctl.c:727",
  "sys/vfs/hammer/hammer_ioctl.c:733-737",
  "sys/vfs/hammer/hammer_ioctl.c:810-814"
 ],
 "poc_changes": "",
 "attempts": 2,
 "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": 60,
 "guest_dirty": 0,
 "build_cmd": "n/a",
 "run_cmd": "n/a",
 "code_hash": "",
 "notes": "",
 "recommended_fix": "hammer_unlock before both error returns"
}