# DF-3113 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

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.

## Kernel references
- sys/vfs/hammer/hammer_ioctl.c:727
- sys/vfs/hammer/hammer_ioctl.c:733-737
- sys/vfs/hammer/hammer_ioctl.c:810-814

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

## Fix

hammer_unlock before both error returns

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

## Reproduction

build: n/a

run: n/a

expected: n/a

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

(none)

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