# DF-4436 — drm_universal_plane_init: format_count>64 error path leaks format_types and the mode-object ID

## Severity / class
Info (probe-time resource leak reachable only through driver
misconfiguration; not attacker-controllable at runtime).
Upstream-inherited: DF's `drm_plane.c` is Linux ~v5.0's file verbatim
(verified by full diff, see below); modern upstream fixed the ordering by
moving the check before `drm_mode_object_add` (today's master has the
`format_count > 64` check at drm_plane.c:386, before object add at :393).

## Root cause
`sys/dev/drm/drm_plane.c`:

- `:193` `drm_mode_object_add(dev, &plane->base, DRM_MODE_OBJECT_PLANE)`
  registers the plane as a mode object (allocates an IDR id).
- `:202-208` `plane->format_types = kmalloc_array(format_count, ...)`.
- `:214-215` `if (WARN_ON(format_count > 64)) return -EINVAL;`

That early `return -EINVAL` skips BOTH `kfree(plane->format_types)` and
`drm_mode_object_unregister(dev, &plane->base)` — unlike the two
neighboring error paths (`:204-208` and `:228-233`) which clean up
properly. Result per failed init: one leaked `kmalloc_array` allocation
(≤ 64*4 = 256 B here since the check triggers only above 64) plus a
leaked mode-object id in `dev->mode_config` (the plane was not yet on
`config->plane_list`, so nothing else will ever release it).

## Trigger
Static driver property: a driver passing `format_count > 64` to
`drm_universal_plane_init()`. No in-tree DragonFly driver does
(i915/radeon/amdgpu all stay well under 64), and the count is not
user-influenced. This is an error-path hygiene defect identical to
upstream v5.0; it costs a WARN plus two small leaks per probe attempt of
a hypothetical misconfigured driver.

## Why not guest-tested
The guest has no DRM device (`/dev/dri` absent) and no in-tree driver
trips the path; the trigger would require writing a new kernel module
with a >64-format plane, which proves nothing beyond what static reading
already proves. Info finding; QEMU verification not warranted.

## Fix
`fix.diff` — move the `format_count > 64` guard above
`drm_mode_object_add` (exactly what upstream did in the
`__drm_universal_plane_init` refactor that current master carries).