# DF-2133: dma_buf_export() never initializes dmabuf->resv

## Verdict: NOT REPRODUCED (HW-gated) — source-confirmed real bug

## Reachability
**NOT reachable on this QEMU guest.** Same as DF-2132: `dma_buf_export()` is in
`drm.ko`, requires a DRM device to reach the export path. No GPU hardware present.

## Mechanism (source-confirmed)
`dma_buf_export()` at `sys/dev/drm/linux_dma-buf.c:117-137`:
1. `kmalloc(sizeof(struct dma_buf), M_DRM, M_WAITOK)` — **no `M_ZERO`**, so all fields
   including `dmabuf->resv` contain uninitialized slab data
2. Sets `priv` (131), `ops` (132), `size` (133), `file` (134)
3. **Never assigns `dmabuf->resv`** even though `exp_info->resv` is populated by callers
   (e.g. `drm_prime.c:548-549` from `dev->driver->gem_prime_res_obj`)

`struct dma_buf` has `resv` as its **first field** (`dma-buf.h:64`). GPU drivers that
access `dmabuf->resv` (e.g. for reservation object locking in `dma_resv_lock`) will
dereference a garbage pointer → kernel crash or arbitrary memory access.

## Primitive
- Class: uninitialized pointer use → potential arbitrary read/write
- `M_DRM` slab bucket content determines what garbage address `resv` holds
- With slab grooming, attacker could shape the residual value

## Fix
`fix.diff`: Add `dmabuf->resv = exp_info->resv;` after `dmabuf->file = fp;` (line 134).
Alternatively, change `M_WAITOK` to `M_WAITOK | M_ZERO`, but explicit assignment is clearer
and matches the Linux upstream API contract.