DF-5704 — equals-walk stack abandonment leaks ancestor locks + extern stack elements

File audited (pass 2): sys/libprop/prop_stack.c (the explicit stack used by the iterative internalize/release/equals walks).

Defect: prop_object_equals_with_error() returns early on a nested type mismatch without draining its _prop_stack (sys/libprop/prop_object.c:1155-1156), violating the stack's pop-to-empty + pot_equals_finish contract. Because _prop_array_equals() / _prop_dictionary_equals() take both objects' rwlocks on the first iteration and keep them held across _PROP_OBJECT_EQUALS_RECURSE (sys/libprop/prop_array.c:219-243, sys/libprop/prop_dictionary.c:503-...), and only pot_equals_finish() (invoked by the finish: drain loop at prop_object.c:1184-1189) releases them, the abandoned stack entries leak:

1. Permanent shared-lock leak on every ancestor pair — in the kernel (struct mtx, prop_object_impl.h:295-300) the shared count never drops, so any later writer of those objects blocks forever (unkillable-thread local DoS); in userland (pthread rwlock, same source) identical.
2. Heap leak of the stack's growth elements — beyond 16 nesting levels each pushed level is a kmalloc/malloc'd _prop_stack_extern_elem (sys/libprop/prop_stack.c:49-63, 40/48 bytes) that is only freed by _prop_stack_pop(); abandoning the stack leaks it.

Kernel reachability today: latent — no in-tree kernel caller drives the nested equals walk (only leaf prop_string_equals_cstring at sys/kern/kern_udev.c:906, sys/dev/disk/dm/device-mapper.c:299). Userland libprop builds the same source (lib/libprop/Makefile:6-13), where prop_array_equals/prop_dictionary_equals are public API and the bug is deterministically reachable by any program comparing nested structures with a nested type mismatch.

Reproduce (guest, root, ~2 min)

sh build.sh      # same-source rig: /usr/src/sys/libprop -> libprop_orig.so + harness
sh run.sh        # A) wedge: control unwedged / buggy wedged (exit 42 = still blocked)
                  # B) leak: RSS 0 -> 19.3 MB over 400k equals() (~48 B/call)

Expected decisive output (run.userland.log):

   -> child STILL BLOCKED in prop_array_add after 5s: rdlock LEAKED (exit 42)
DF-5704 wedge result: REPRODUCED (control unwedged, buggy wedged)
  [leak] after 400000 equals(): ru_maxrss = 19352 kB

Fix validation

fix.diff routes the type mismatch through the existing finish: drain (one-line change in sys/libprop/prop_object.c). Applied to the same rig (propfix/), rebuilt, re-run: buggy case add returned TRUE (no wedge), RSS flat at ~1010 kB over 400k equals() (fixtest.userland.log).

DF-5704 VERDICT — REPRODUCED (deterministic, same-source userland differential; kernel-latent today)

What was claimed

Auditing sys/libprop/prop_stack.c (pass 2) against its contract revealed the equals walk violates the stack's drain discipline: on a nested type mismatch prop_object_equals_with_error() returns false immediately instead of unwinding its _prop_stack. Each abandoned stack level represents an ancestor pair whose shared locks are still held (taken by _prop_array_equals/_prop_dictionary_equals at first iteration, released only by pot_equals_finish during the finish: drain) plus — beyond 16 levels — a heap-allocated _prop_stack_extern_elem that only _prop_stack_pop() frees.

Why it is a real bug (path:line)

• sys/libprop/prop_object.c:1155-1156 — if (po1->po_type != po2->po_type) return (false); — the only exit of the walk that skips the finish: drain at prop_object.c:1184-1189.
• sys/libprop/prop_array.c:219-227 — both pa_rwlocks rd-locked at idx==0 (address-ordered);
• sys/libprop/prop_array.c:240-243 — _PROP_OBJECT_EQUALS_RECURSE returned with the locks held;
• sys/libprop/prop_array.c:251-256 — _prop_array_equals_finish unlocks both (only called from the drain);
• same pattern for dictionaries: sys/libprop/prop_dictionary.c:503-511.
• sys/libprop/prop_stack.c:49-63 — push beyond PROP_STACK_INTERN_ELEMS (16) heap-allocates _prop_stack_extern_elem (_PROP_MALLOC), freed only at prop_stack.c:101 inside _prop_stack_pop.
• Stack contract documented by construction: every other exit drains (prop_object.c:638-641, 650-656, 1106, 1165-1170, 1184-1188); the equals type-mismatch exit is the sole violation.

How it was proven (guest, DragonFly 6.5-DEVELOPMENT)

Same-source rig (the established pattern): /usr/src/sys/libprop compiled into libprop_orig.so on the guest, harness linked against it — the bytes executed are the kernel's own source text.

A) Wedge (deterministic, 3/3 runs + 1 initial = 4/4): a1=["x"] vs a2=[5] — type mismatch at depth 1. - Control (a1=["x"] vs a2=["y"] — types match): equals -> 0, then prop_array_add returns immediately (FALSE path drains correctly). - Buggy: equals -> 0, then prop_array_add never returns; SIGALRM(5s) handler _exit(42)s from inside the blocked call. ⇒ the rdlock taken by _prop_array_equals on a1 (and a2) was leaked by the abandoned stack entry; the write path (prop_array_add → _PROP_RWLOCK_WRLOCK, prop_array.c:638) blocks forever. In-kernel equivalent: struct mtx shared count never drops → any writer of the object wedges forever in _mtx_lock_ex (kernel thread DoS).

B) Heap leak of the growth elements: 17-deep chains, mismatch at the leaf — exactly one _prop_stack_extern_elem is live on the stack at the moment of abandonment. 400,000 prop_array_equals() on the same pair: ru_maxrss 0 → 19,352 kB (~48 B/iteration = one malloc chunk per call, matching prediction iters × 48B ≈ 18,750 kB).

Exploit chain / impact ceiling

• Userland libprop (same source, shipped as /lib/libprop): any program that compares attacker- or data-influenced nested plists with a nested type mismatch permanently wedges a thread on the next mutation of those objects and leaks memory per comparison. Local DoS, deterministic.
• Kernel: the identical code compiled into the kernel; today no in-tree caller drives the nested equals walk (verified: only prop_string_equals_cstring at sys/kern/kern_udev.c:906 and sys/dev/disk/dm/device-mapper.c:299 — leaf compares, no stack). Any future kernel consumer of prop_array_equals/prop_dictionary_equals/ prop_object_equals on attacker-shaped plists inherits a permanent kernel-lock leak → unkillable blocked threads (local DoS). Not uid0-able: the primitive is a lock/heap leak, not memory corruption.

Fix validation

fix.diff (one line, sys/libprop/prop_object.c): route the type mismatch through the existing finish: drain (goto finish;). The drain pops every ancestor and calls its pot_equals_finish (unlock), then returns false — semantics preserved. Validated in the same rig (propfix/): - buggy case: add returned TRUE (no wedge) — wedge GONE; - leak case: ru_maxrss flat at 1,008-1,028 kB across 400k equals() — leak GONE; - control case: unchanged.

Classification

status: reproduced, impact: dos (permanent rwlock wedge + unbounded heap leak; deterministic in userland libprop today, latent in kernel), confidence: certain (mechanism proven at 4/4 determinism with control, leak quantified to the byte, fix validated same-source).

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.