# DF-2240 - Verification Verdict

**Status:** reproduced
**Impact:** none (hardening)
**Confidence:** certain

## Mechanism
The prop_array_add_uint{8,16,32,64} template instantiates prop_number_create_integer((int64_t)val) - the SIGNED creator - while prop_array_set_uint* correctly uses prop_number_create_unsigned_integer. A value with its top data bit set is stored as a signed prop_number one width class larger (prop_number_size returns 64 for 2^31, 32 for 2^15, 16 for 2^7), so prop_array_get_uintN (which rejects size>N) cannot read it back.

## Verdict
REPRODUCED on the stock guest with the userland libprop (same sources as sys/libprop): add_uint8(0xff), add_uint16(0xffff), add_uint32(0xffffffff), add_uint64(0xffffffffffffffff) all store, but every matching get_uintN returns false; control values with the top bit clear round-trip fine at all four widths. Signed round-trip semantics broken for exactly the values the unsigned API exists for.

## Threat / reachability
API correctness: kernel/userland consumers using add_uintN + get_uintN silently lose values >= 2^(N-1); no direct memory-safety impact.

## Privilege escalation assessment
n/a (API semantics)

## Fix
Use prop_number_create_unsigned_integer((uint64_t)val) in the add_uint template, matching set_uint.

## Kernel references
- `sys/libprop/prop_array_util.c:187`

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