# DF-5677 — VERDICT

**reproduced (deterministic unit-level) / impact=dos (userland-only; kernel path unreachable today) / confidence=certain**

## Reproduced

TU-include harness reaches the static `prop_object_release_emergency` with a
refcount-2 array — the deterministic equivalent of the first-iteration
`ocnt != 1` break (a concurrent retain racing the restored refcount):

```
Assertion failed: (parent), function prop_object_release_emergency,
file proporig/prop_object.c, line 1048.   -> abort (134)
NDEBUG build:                              -> SIGSEGV (139)
```

## Why kernel impact is nil today (and honestly scoped)

The emergency path is entered from `prop_object_release` only when `pot_free`
returns `_PROP_OBJECT_FREE_FAILED`; for array/dict that requires
`_prop_stack_push` to fail, i.e. a `malloc` failure. Kernel `_PROP_MALLOC` =
`kmalloc(M_WAITOK)` — cannot return NULL (DragonFly panics on malloc-limit
excess instead, sys/kern/kern_kmalloc.c:706). So in the shipped kernel the
defect is dead code; it is live for userland libprop under memory pressure and
would become kernel-live if the allocation ever flips to M_NOWAIT.

Related observations recorded in the same function (not separately filed):
`pot_emergency_free(parent)` is invoked without the type lock held, and the
refcount restore (`atomic_inc_32`, prop_object.c:1046/1102) runs outside the
lock — both matter only on the same malloc-failure/race edge, and DF-5674
already tracks the pot_lock contract hole for this family.

## Fix validation

`if (parent == NULL) return;` — nothing was walked, so there is nothing to
emergency-free. Fixed rig: assert and NDEBUG builds both survive (exit 0).

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