DF-5682 — prop_number_unsigned() is the only unguarded prop_number accessor (type-confused OOB read)

What

prop_number_unsigned() (sys/libprop/prop_number.c:379-384) reads pn->pn_value.pnv_is_unsigned without the prop_object_is_number() validation that every sibling accessor performs:

• prop_number_copy prop_number.c:364
• prop_number_size prop_number.c:396
• prop_number_integer_value prop_number.c:432
• prop_number_unsigned_integer_value prop_number.c:450
• prop_number_equals prop_number.c:463
• prop_number_equals_integer prop_number.c:477
• prop_number_equals_unsigned_integer prop_number.c:496

Layout: struct _prop_number places pn_value at offset 40 (16-byte _prop_object + 24-byte rb_node); the bitfield word lives at +40..43. struct _prop_string is exactly 40 bytes (16 + ptr + size_t + int). Calling prop_number_unsigned() on a string (or data / bool — 16 bytes — object) therefore reads 4 bytes entirely past the heap allocation:

   0                   16                  40
   +-------------------+-------------------+---------+
   | _prop_string      | data/size/flags   | GUARD / adjacent chunk
   +-------------------+-------------------+---------+
                                            ^ pnv_is_unsigned read (+40..43)

Kernel reachability today: none — rg finds zero in-kernel callers of prop_number_unsigned() outside libprop itself (the only kernel consumers of prop_number creation are kern_udev.c:195,215, create-side and type-safe). The defect is a live memory-safety trap one future caller away from a user-influencible plist type confusion, and it is present verbatim in the userland libprop.so built from the same source. Filed as hardening (Info): certain code defect, no demonstrated kernel impact.

Reproduce (rig — guard-page heap on the QEMU guest)

build.sh compiles the guest's /usr/src/sys/libprop (md5-identical to the audited tree) twice, with _PROP_POOL_GET/ _PROP_POOL_PUT patched (userland branch of prop_object_impl.h) to place every proplib object allocation flush against a PROT_NONE guard page — deterministic, ASAN-free boundary detection (guest base cc 8.3 ships no usable ASAN runtime):

• prop5682_pg — guard-page allocator + stock prop_number.c
• prop5682_fix — guard-page allocator + prop_number.c with the prop_object_is_number() guard added (pfix_number.c = the exact fix.diff under test)

typeconf.c creates one prop_string_t, then:

1. control — prop_number_integer_value((prop_number_t)str): the guarded sibling, must return 0 without trapping;
2. probe — prop_number_unsigned((prop_number_t)str): the unguarded accessor.

Expected / observed (run.log, 2026-10-10)

The 4-byte OOB read at +40 is proven deterministically, and the fix is validated on the same source.

Fix

fix.diff — add the missing guard, matching every sibling accessor:

 bool
 prop_number_unsigned(prop_number_t pn)
 {

+   if (! prop_object_is_number(pn))
+       return (false);
+
    return (pn->pn_value.pnv_is_unsigned);
 }

DF-5682 — VERDICT

Status: reproduced (primitive, deterministic, same-source userland rig) — kernel impact today: none reachable (zero in-kernel callers); filed as Info/hardening.

The finding

prop_number_unsigned() (prop_number.c:379-384) is the only prop_number accessor lacking the prop_object_is_number() guard its siblings have (prop_number.c:364, 396, 432, 450, 463, 477, 496). It reads the pnv_is_unsigned bitfield word at offset +40..43 of the object. struct _prop_string is exactly 40 bytes; struct _prop_bool is 16. Passing any non-number object therefore reads 4 bytes entirely past the heap allocation — a type-confusion OOB read.

Reachability (honest)

• Kernel: rg over sys/ finds zero callers of prop_number_unsigned() outside libprop itself; the only kernel prop_number consumers are prop_number_create_integer / prop_number_create_unsigned_integer in sys/kern/kern_udev.c:195,215 (create-side, type-safe). One future caller that fetches a value from a user-influenced plist by key and passes it untyped turns this into a kernel heap OOB read — hence hardening, not an exploitable finding today.
• Userland: lib/libprop builds the same source into libprop.so; any consumer that type-confuses gets the same OOB read in-process.

What was demonstrated (run.log)

Guard-page rig on the QEMU guest: guest /usr/src/sys/libprop (md5-identical to the audited tree, verified) compiled with _PROP_POOL_GET/_PROP_POOL_PUT placing every object allocation flush against a PROT_NONE page (deterministic boundary detection; guest base cc 8.3 has no usable ASAN runtime).

1. Control — prop_number_integer_value((prop_number_t)str) (guarded sibling): returns 0, no trap — proves the guard works and the object/pool wiring is correct.
2. Probe — prop_number_unsigned((prop_number_t)str) (unguarded): SIGSEGV, exit 139 on the guard page — the +40..43 read lands past the 40-byte allocation. Deterministic.
3. Fix — same rig with pfix_number.c (the exact fix.diff): probe returns false, no trap, exit 0. Fix validated on the same source.

Fix validation

fix.diff adds the missing guard, matching every sibling accessor. Validated in-rig (baseline traps 139, patched survives) — this is a pure source-level change to a userland-buildable file, so the rig validation is representative of the kernel build as well (kernel compile of the guarded function is straightforward C; no kernel-only macro is involved on this path).

Kernel refs

• sys/libprop/prop_number.c:49-62 (layout), 379-384 (defect), 364/396/432/450/463/477/496 (guarded siblings)
• sys/libprop/prop_string.c:40-50 (struct size)
• sys/libprop/prop_object_impl.h:364-365 (userland pool = malloc)

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.