DF-2132 — VERDICT: REPRODUCED (production code, deterministic) + FIX VALIDATED

Status: reproduced. Impact: kernel memory corruption (UAF / refcount-underflow → premature free with dangling fd-table reference); deterministic; unprivileged trigger context; no race required. Confidence: certain.

1. Root cause (source-traced, line-accurate)

dma_buf_get() — sys/dev/drm/linux_dma-buf.c:168-187:

if ((fp = holdfp(curthread, fd, -1)) == NULL)      /* :174 borrow */
        return ERR_PTR(-EBADF);
...
dmabuf = fp->private_data;                         /* :183 */
dropfp(curthread, fd, fp);                         /* :184 return borrow */
return dmabuf;                                     /* :186 ZERO owned refs */

holdfp() (kern_descrip.c:2765) returns either a borrowed per-thread fd-cache reference (fast path, +0) or a newly-fholded reference that dropfp() (kern_descrip.c:510) hands to the fd cache — in both cases the net f_count change across the dma_buf_get() body is zero, and the returned dmabuf owns nothing.

dma_buf_put() — sys/dev/drm/include/linux/dma-buf.h:110-120 (production static inline, compiled into drm_prime.c):

static inline void dma_buf_put(struct dma_buf *dmabuf) {
        ...
        fdrop(dmabuf->file);                        /* unconditional -1 */
}

Caller composition — drm_gem_prime_fd_to_handle(), sys/dev/drm/drm_prime.c:795-866:

• :802 dma_buf = dma_buf_get(prime_fd); (0 owned refs)
• :812-814 lookup-hit (ret == 0) → goto out_put
• :864 out_put: ... dma_buf_put(dma_buf); → fdrop of a reference the caller never acquired
• error path :857 (via out_unlock → out_put) — same over-drop.
• The success path (:831 get_dma_buf fhold, :848 dma_buf_put fdrop) is count-neutral at that moment, but the reference it stores on the GEM object (obj->dma_buf) is phantom: when the object is later destroyed, drm_gem.c:271 dma_buf_put(obj->dma_buf) drops yet another unowned reference — the same underflow, delayed.

In Linux, dma_buf_get() uses fget() and returns owning one reference, which the caller's dma_buf_put() (fput) consumes — balanced. The DragonFly port dropped the ownership transfer and kept the put.

2. Observable arithmetic (measured on the guest, production drm.ko)

dma_buf_export() (linux_dma-buf.c:118-137) fallocs the file (f_count=1, kern_descrip.c:2118) and dma_buf_fd() (linux_dma-buf.c:139-166) fsetfds it (+1, kern_descrip.c:2190); neither ever drops the falloc reference (a production leak that masks exactly one over-drop). Resting count after export: 2, plus one transient fd-cache reference once any holdfp runs.

Measured with the rig (console record, logs/panic_modeB_final.txt):

[export] cpu2 dma_buf fd=4 fp=0xfffff80116c4ce00 f_count=2
[import] fd=4 f_count 3->2 (over-drop: put consumed a ref nobody acquired)
[import] fd=4 f_count 2->1 (over-drop)
[import] fd=4 f_count 1->0: *** STRUCT FILE FREED INSIDE dma_buf_put
         WHILE FD-TABLE SLOT STILL REFERENCES IT ***
[info]   fd=4 release_count=3 slot_valid=1 slot_is_saved=1
[user]   mode B: premature free CONFIRMED, slot dangling
panic: fdrop: invalid f_count -1
        kern_close() -> closef() -> fdrop()

The 1→0 transition happens inside dma_buf_put() → fdrop() (kern_descrip.c:3120-3175): LIST_REMOVE from the filehead, fo_close = dmabuf_close (linux_dma-buf.c:55-68: ops->release + kfree(dmabuf)), ffree → kfree_obj(fp, M_FILE) — while the fd-table slot and the thread fd-cache entry still point at the freed chunk (proven by slot_is_saved=1, read under fd_spin without dereferencing).

3. Use-after-free manifestations (all observed)

1. close(dangling_fd) → kern_close → funsetfd_locked → fclearcache (kern_descrip.c:247) does a raw atomic_add_int(&fp->f_count, -1) on freed memory (silent UAF write → −1), then closef → fdrop reads the poisoned count: panic: fdrop: invalid f_count -1 (INVARIANTS tripwire).
2. Earlier variant (two over-drops, then close): the fclearcache write lands while the chunk is still the live-but-undercounted file → panic: fdrop: invalid f_count 0 (logs/panic_modeA_closeafter2imports.txt).
3. On a production (noinv) kernel these tripwires do not exist: the silent primitives below run to completion.

4. Exploitation push (mode c — demonstrated)

• Reclaim: DF's kmalloc_obj allocator (kern_kmalloc.c:680,926) is a per-slab FIFO ring (free pushes at findex tail, alloc pops at aindex head), not LIFO — a naive spray misses. A ~960-allocation bare falloc spray (rig, same process) reoccupies the freed chunk: dummy file fd=952 REOCCUPIED the freed chunk.
• Cross-type alias: freeing that dummy returns the chunk to the (now shallow) ring; a plain userland open("/dev/null") lands on the exact freed address (fp=0x...daf700 == saved fp).
• Functional UAF: read() through the dangling dma-buf fd succeeds (returns 0 = EOF, dispatched via the reclaimed file's ops) — the fd-table slot now serves an unrelated object type.
• Silent reference steal: close() of the aliased fd frees the object again while the dangling fd still references it — re-arming the dangling state at will, count-silent (no KASSERT on any kernel).

Remaining distance to uid=0 (honest assessment)

M_FILE is a dedicated MALLOC_DEFINE_OBJ zone (kern_descrip.c:112) of sizeof(struct file) chunks — arbitrary attacker content cannot be placed there directly; only real struct files. The demonstrated route (consistent with historical BSD file-UAF exploits) is the aliasing primitive: two fd-table slots referencing one fp let the attacker drive any file object to a premature free at a chosen moment (steal), leaving dangling references in subsystems that hold raw fp pointers without refcounts (knote lists, struct kqueue/poll registrations, blocked syscall threads) — then reclaim the chunk with a file of a different type and reach a f_ops/f_data type confusion, which on this guest (no SMAP/SMEP/KASLR) is a direct function-pointer hijack → ROP → cred overwrite. This weaponization was not completed in this run: each candidate confusion partner on this INVARIANTS kernel trips a KASSERT early by design, and the raw-fp-holder races need dedicated grooming work. The primitive set (deterministic premature free, cross-type functional aliasing, repeatable silent steal) is demonstrated; feasibility of the final step is assessed as high but unproven here.

5. Reachability

• Real hardware: any DRM driver with PRIME (i915/amdgpu/radeon) — unprivileged render-node ioctls (DRM_IOCTL_PRIME_HANDLE_TO_FD then repeated DRM_IOCTL_PRIME_FD_TO_HANDLE), single-threaded, deterministic. See the finding markdown for the exact ioctl sequence.
• This guest: no GPU → no /dev/dri (see reachability.txt), so the PoC drives the identical production code via the KLD rig (/dev/df2132, 0666, unprivileged trigger context). The rig adds no DRM behavior of its own; it supplies only the dma_buf_ops stand-in a GEM driver would supply and reports observable state.

6. Fix validation

fix.diff (one hunk, linux_dma-buf.c:183): fhold(fp) before dropfp() — the caller-owned reference dma_buf_put() expects.

Patched module: fix_build.log (link line + size), runs: fix_run.log.

7. Artifacts index

• run.log — combined decisive baseline record
• run_A.log — oracle runs (2×, bug present)
• run_c.out — user-side exploit-push record
• logs/panic_modeB_final.txt, logs/panic_modeB_full.txt — premature-free panics
• logs/panic_modeA_closeafter2imports.txt — f_count-0 close variant
• logs/panic_modeC_full.txt, logs/dmesg_mode_c.txt — alias/steal + final panic
• logs/mode_c_run2.txt — FIFO-ring spray-miss instrumentation (allocator behavior)
• build.log, setup.log — in-guest build + production-code identity (md5)
• fix.diff, fix_build.log, fix_run.log — fix + validation

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.