hammer_ioc_add_snapshot / hammer_ioc_del_snapshot return with hmp->snapshot_lock held when hammer_init_cursor fails — permanent snapshot-subsystem lockup on production kernels
Summary
Both handlers take hammer_lock_ex(&hmp->snapshot_lock) (:727, :804) and then 'return(error)' directly from the hammer_init_cursor failure path (:733-737, :810-814) without unlocking - unlike the success path (:780, :845). On INVARIANTS kernels hammer_init_cursor's failure hits KKASSERT(error==0) at hammer_cursor.c:202 and panics first; on production builds the error propagates out with the lock exclusively held, permanently blocking every later snapshot ioctl and 'hammer cleanup' (which serializes on snapshot_lock). Root-gated trigger (cursor-init failure = degraded media); availability only. Same error-path-lock-leak class as DF-0839, different lock and trigger. Not dynamically triggerable on the INVARIANTS guest; code-proven. Fix: unlock before both error returns. [VERIFIED pass2: production-only leak - INVARIANTS KKASSERT fires first live-demonstrated via DF-3109; fix compile-validated]
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-3113 · 9 files| File | Type | Description | Size | |
|---|---|---|---|---|
| fix.diff | — | 854 B | view raw | |
| README.md | — | 375 B | ↓ raw | |
| VERDICT.md | — | 1.6 KB | ↓ raw | |
| build.sh | — | 106 B | view raw | |
| run.sh | — | 88 B | view raw | |
| manifest.json | — | 491 B | view raw | |
| verdict.json | — | 1.4 KB | view raw | |
| fix.diff | — | 854 B | view raw | |
| env.txt | — | 272 B | view raw |
DF-3113 -- verification pack
Finding: snapshot add/del return with snapshot_lock held when init_cursor fails
Status: not_reproduced / impact denial_of_service / confidence certain
What was run
n/a
How to reproduce
n/a
Expected
n/a
See VERDICT.md for the full narrative and verdict.json for the persisted machine verdict. Artifacts: fix.diff.
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.
Fix verification
not_testableConfirmed kernel references
Detail
Evidence (decisive lines)
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
Verified recommended fix
hammer_unlock before both error returns
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.
No comments yet.