# DF-2165: shmem_read_mapping_page() leaks VM_OBJECT_LOCK on every error path

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

## Reachability
**NOT reachable on this QEMU guest.** `shmem_read_mapping_page()` is in
`sys/dev/drm/linux_shmem.c`, part of `drm.ko`. Called from DRM drivers' GEM object
page management (e.g. `pagecache_write_begin`, i915 GEM backing-store). Without GPU
hardware, these paths are unreachable.

## Mechanism (source-confirmed)
`shmem_read_mapping_page()` at `linux_shmem.c:46-87`:
1. Line 52: `VM_OBJECT_LOCK(object)` — acquires VM object lock (refcount + token)
2. Four error-return paths return `ERR_PTR(-ENOMEM)` **WITHOUT** calling `VM_OBJECT_UNLOCK`:
   - Line 57: `if (m == NULL) return ERR_PTR(-ENOMEM);` (OBJT_MGTDEVICE path)
   - Line 60: `if (rv != VM_PAGER_OK) { vm_page_free(m); return ERR_PTR(-ENOMEM); }`
   - Line 70: `if (m == NULL) return ERR_PTR(-ENOMEM);` (normal path, lookup failed)
   - Line 73: `if (rv != VM_PAGER_OK) { vm_page_free(m); return ERR_PTR(-ENOMEM); }`
3. Line 84: `VM_OBJECT_UNLOCK(object)` — only reached on the success path

Each error return permanently leaks:
- The VM object lockmgr token (permanently held → blocks all VM object operations)
- `hold_count` increment (never decremented → object never freed)
- May exhaust token pool or cause permanent hangs

Under memory pressure (when `vm_pager_get_page` fails), this bug triggers reliably,
progressively locking VM objects until the system hangs.

## Primitive
- Class: resource leak (lock + refcount) → progressive system degradation → DoS
- Each error path leaks one VM object lock permanently
- Under memory pressure, multiple objects get locked → system-wide hang

## Fix
`fix.diff`: Add `VM_OBJECT_UNLOCK(object);` before each of the four `return ERR_PTR(-ENOMEM);`
statements. Also adds braces to the single-line `if` statements to properly scope the unlock.