DF-2941 VERDICT — put-side count==0 acceptance in _sysref_put

Finding

_sysref_put() (sys/kern/kern_sysref.c:297-360) has no floor guard on the put side. The branch

} else if (count > -0x40000000) {          /* kern_sysref.c:329 */
    if (atomic_cmpset_int(&sr->refcnt, count, count - 1))

also accepts count == 0, so a double-release (a second sysref_put() for a reference that was already dropped) silently decrements a fully-released object 0 -> -1 -> -2 -> ... with no structural rejection. The only barrier is the debug-only KKASSERT((sr->flags & SRF_PUTAWAY) == 0) at kern_sysref.c:303 (and the same assert inlined in sysref_put, sys/sysref2.h:85) — and that assert reads sr->flags non-atomically with respect to the release sequence in the final branch:

if (atomic_cmpset_int(&sr->refcnt, count, 0)) {   /* :346 count -> 0  */
    KKASSERT(sr->flags & SRF_ALLOCATED);
    sr->flags |= SRF_PUTAWAY;                 /* :348 flags RMW     */

A double-put racing into _sysref_put between :346 and :348 observes refcnt == 0 with SRF_PUTAWAY not yet visible, passes the entry assert, and is accepted by the :329 branch — even on INVARIANTS kernels. After :348 the assert does catch it, but only on debug builds; production kernels compile KKASSERT out entirely and accept every double-release silently.

Reproduction (guest, stock INVARIANTS kernel #0)

sysref_probe.c defines a synthetic sysref_class (lockmgr-based lock/unlock, terminate callback mirroring devfs_cdev_terminate's protocol: unlock, then drop the terminal ref) and drives the layer:

• B1 — normal sysref_alloc → sysref_activate → get → put → put cycle completes to putaway (refcnt=0, flags=0x6 = SRF_ALLOCATED|SRF_PUTAWAY). Run log: run.log:4 "B1: normal cycle refcnt=0 flags=0006 term_count=1 (putaway)".
• B2 — fault injection clearing SRF_PUTAWAY to emulate the exact state a racing put sees between :346 and :348, then one extra sysref_put(). Observed: run.log:6 "B2: layer ACCEPTED double-release: refcnt=-1 (walked 0 -> -1; count > -0x40000000 branch, no floor guard)" — the underflow was accepted on the INVARIANTS kernel. State was then repaired by the probe.
• B3 — a real post-putaway double-put (no injection). Observed: panic: assertion "(sr->flags & SRF_PUTAWAY) == 0" failed in _sysref_put at /usr/src/sys/kern/kern_sysref.c:303 (panic.txt, backtrace _sysref_put ← sysref_probe_modevent ← linker_load_module).

Impact assessment (honest ceiling)

• The layer offers no structural defense against double-releases; the debug-only assert is the whole barrier and is racy w.r.t. its own release sequence.
• Consequences of an accepted double-release on a production kernel: the object's refcount is driven into permanent negative limbo (the object has already terminated and been returned to the objcache magazine; the spurious negative count is only observable at the next sysref_alloc() of the chunk, where KKASSERT(sr->refcnt == 0) (kern_sysref.c:163) fires on debug builds and is overwritten silently on production builds). Reaching a second objcache_put() of the same object requires ~2^30 additional puts, so the realistic ceiling of a single double-release is silent state corruption / loss of detection, not an immediate double-free.
• Attacker reachability: none found in-tree. No syscall path performs an unpaired sysref_put(); the finding is that any future caller bug of that shape is silently swallowed by the layer on production builds instead of being caught at the earliest point. This is why the finding is filed as Info (hardening), severity consistent with the existing DF-0169 (get-side overflow guard absence).

Kernel references

• sys/kern/kern_sysref.c:305-336 — the accepting branch
• sys/kern/kern_sysref.c:345-355 — final release; :346 cmpset → :348 non-atomic flags |= SRF_PUTAWAY window
• sys/kern/kern_sysref.c:303 — the only guard (debug-only, racy)
• sys/sys/sysref2.h:79-88 — inline sysref_put entry assert (same)
• sys/kern/kern_sysref.c:163 — recycle-time detection point

Fix

Reject count == 0 loudly in _sysref_put (see fix.diff): a dedicated branch for count == 0 that panics on INVARIANTS and, on all builds, does not decrement — this converts the silent underflow into a hard, immediately-diagnosable failure at the point of misuse. Fix authored post-verification; not build-validated (Info hardening finding; the fix is assert/plumbing-level and the behavior change is the panic itself).