DF-2922 — proplib type confusion in sys_vquotactl → kernel memory corruption / panic / livelock

What

sys/kern/vfs_quota.c:385 passes the user-controlled "arguments" proplib object to cmd_set_usage_all(), which calls prop_array_iterator(args) at sys/kern/vfs_quota.c:242 without validating that the object is an array. prop_array_iterator() (sys/libprop/prop_array.c:538-546) executes mtx_lock(&pa->pa_rwlock) — in-kernel proplib rwlocks are real sleep mutexes (sys/libprop/prop_object_impl.h:295-299) — before the prop_object_is_array() type check inside _prop_array_iterator_locked().

For a non-array object the 40-byte struct mtx at offsetof(struct _prop_array, pa_rwlock) == 16 aliases other fields of the real object:

All triggered by an unprivileged user (uid 1001) with vfs.quota_enabled=1 (the same reachability already established by DF-0141).

Additionally the fault happens with ac_spin held (cmd_set_usage_all takes the mount spinlock at vfs_quota.c:228 before calling prop_array_iterator) — the compounding "sleep/spin under spinlock" defect.

Files

• typeconfuse.c — trigger (mode selectable)
• build.sh / run.sh
• panic.false.txt, panic.true.txt, panic.number.txt — serial console captures
• panic.dump.txt — auto-backtrace from crash dump (debugger_on_panic=0)
• disasm.txt — disassembly proving the faulting stores/loads are the __mtx_lock_ex exlink-list manipulation
• bss-layout.txt — nm proof of the _prop_bool_* global layout the aliased mutex overwrites
• fix.diff — validated fix (type checks + stack initialization)
• verdict.json / manifest.json

Build

cc -O -o typeconfuse typeconfuse.c -lprop

Run (on a guest booted with vfs.quota_enabled=1)

# control (returns cleanly):
./typeconfuse /boot dict
# each of the following kills the stock kernel deterministically:
./typeconfuse /boot false     # fatal trap 12, page fault, spinlock held
./typeconfuse /boot true      # fatal trap 9 GPF (write through aliased ptr)
./typeconfuse /boot number    # fatal trap 9 GPF (read through aliased ptr)
./typeconfuse /boot string    # silent full-system kernel livelock

Expected output (baseline, unpatched)

false: mode=false path=/boot pid=N then the console shows Fatal user address access from kernel mode from typeconfuse at ffffffff809d780f / panic: page fault / panic with 1 spinlocks held.

On the patched kernel every variant returns vquotactl returned 22 (EINVAL) and the guest stays up.

DF-2922 VERDICT — REPRODUCED (kernel memory corruption / panic / livelock, unprivileged)

Guest: DragonFly 6.5-DEVELOPMENT #0 (X86_64_GENERIC, INVARIANTS), vfs.quota_enabled=1 (boot tunable), attacker = uid 1001 (maxx) over ssh.

Root cause (source-proven)

• sys/kern/vfs_quota.c:385 cmd_set_usage_all(nch.mount, args) — args is prop_dictionary_get(dict, "arguments") (sys/kern/vfs_quota.c:367), an arbitrary proplib object type fully controlled by the caller's plist.
• sys/kern/vfs_quota.c:242 prop_array_iterator(args) with no type check.
• sys/libprop/prop_array.c:538-546: _PROP_RWLOCK_RDLOCK(pa->pa_rwlock) (= mtx_lock(), sys/libprop/prop_object_impl.h:297) executes BEFORE the prop_object_is_array() check inside _prop_array_iterator_locked() (prop_array.c:513-536). offsetof(struct _prop_array, pa_rwlock) is 16; the 40-byte struct mtx (sys/sys/mutex.h:66) then aliases whatever the real object keeps at +16..+56:
• _prop_number: pn_link rb_node (sys/libprop/prop_number.c:51)
• _prop_string: ps_mutable/ps_size/ps_flags (prop_string.c:40-48)
• _prop_bool: pb_value + past-object globals (prop_bool.c:35-41; nm shows _prop_bool_false @0xffffffff8179b300, _prop_bool_true @0xffffffff8179b320, _prop_data_pool @0xffffffff8179b338 — the mtx's owner/exlink/shlink/ident fields at +24/+32/+40/+48 land on/around these globals and past them).
• The contention slowpath __mtx_lock_ex (sys/kern/kern_mutex.c:85-200) writes MTX_EXWANTED|MTX_LINKSPIN into the aliased lock word, stores a kernel stack pointer through mtx->mtx_exlink (list enqueue, kern_mutex.c:153-163), and dereferences the chain — on memory that is not a mutex.
• Compounding defect: cmd_set_usage_all holds the mount's ac_spin spinlock (vfs_quota.c:228) across the call — the sleeping/spinning mutex path then runs with a spinlock held ("panic with 1 spinlocks held").

Reproduction (all unprivileged, 5 independent knockdowns)

1. false (fresh boot): console Fatal user address access from kernel mode from typeconfuse at ffffffff809d780f; Fatal trap 12: page fault; fault virtual address = 0x40; backtrace from the crash dump: strncpy ← _mtx_lock_ex+0x130 (the callq mtx_wait_link return — the sleep path copies mtx->mtx_ident as the tsleep wchan string); panic with 1 spinlocks held; panic: page fault; dump saved to /var/crash/vmcore.0. Deterministic 3/3 fresh boots.
2. true: Fatal trap 9: general protection fault, RIP _mtx_lock_ex+0xdc = movq %r12,(%rax) — the exlink enqueue writing a kernel stack pointer through the aliased mtx_exlink.
3. number (31337): Fatal trap 9, RIP _mtx_lock_ex+0xc4 = movq 0x8(%rax),%rcx — read side of the same exlink walk.
4. string: NO trap — the aliased lock word is the low 32 bits of the heap ps_mutable pointer (never 0), so __mtx_lock_ex's retry loop spins forever in kernel mode with ac_spin held: QEMU pinned at 102% CPU, guest OS dead, serial console silent. Full-system livelock from a single unprivileged syscall.
5. Control dict: same-shaped object (dictionary rwlock at the same offset), returns cleanly — the plumbing works and only the object TYPE decides the outcome.

Primitive characterization

• write: mtx->mtx_exlink = link / link->next->prev = link — writes a kernel-stack pointer to an address derived from aliased object bytes (for string, heap bytes the attacker shapes via plist content → write-what(kernel-stack-addr)-where(aliased-ptr) potential with pool grooming).
• write: mtx->mtx_owner = curthread past the end of _prop_bool_false (8-byte OOB write on a static global, masked only by linker padding on this build).
• sleep/spin-while-holding-ac_spin: unkillable thread / livelock.
• Full uid=0 chain (pool-groom _prop_string_pool so the aliased exlink points at attacker-shaped heap; the enqueue then writes a stack pointer at a controlled address, e.g. a pooled object's refcount/type) was NOT completed — the corruption primitive itself is proven above; the reliable panic/livelock is the shipped impact.

Fix validation

fix.diff (type validation of "arguments" and per-element dicts + zero initialization of space/limit) applied to the guest's /usr/src, make nativekernel, installed, rebooted: * all four knockdown variants return EINVAL (22) cleanly, guest stays up, * the leak PoC (DF-2925) then reports ac_limit=0 (initialization fix). Baseline (unpatched) re-confirmed immediately beforehand in the same session flow.

References

sys/kern/vfs_quota.c:228,242,249,277,293,314,367,385; sys/libprop/prop_array.c:513-546; sys/libprop/prop_object_impl.h:295-299; sys/sys/mutex.h:66; sys/kern/kern_mutex.c:85-200,209; sys/kern/kern_kmalloc.c:706 (limit-panic policy, cf. DF-2926).