# VERDICT -- DF-2017 (Low)

**Verdict:** REPRODUCED (source-only)

**Impact:** DRM master refcount leak / mastership theft (logic); HW-gated (needs DRM/GPU), source-confirmed

**Confidence:** certain

## Mechanism (source-traced)

drm_setmaster_ioctl (drm_auth.c:181-260) has the 'if (dev->master) { ret=-EINVAL; goto out_unlock; }' exclusivity guard COMMENTED OUT (drm_auth.c:197-201, the ret/goto lines are '//ret = -EINVAL; //goto out_unlock;' with an 'XXX fixme' comment). With it disabled, a CAP_SYS_ADMIN caller proceeds into drm_new_set_master -> drm_set_master which does dev->master = drm_master_get(fpriv->master) (drm_auth.c:127) -- a raw assignment with no drm_master_put of the prior dev->master, stranding the old master object refcount.

## Why not runtime-reproduced

The guest (DragonFlyBSD 6.5-DEVELOPMENT #0 master DEV, KVM) has NO matching
hardware: pciconf shows no mfi/tws/iir RAID controller and no amdgpu/DRM GPU;
the driver therefore cannot attach and the vulnerable path is not runtime-
triggerable here. The defect was **confirmed at the source level** by tracing
the cited `path:line` against `sys/`, and the proposed fix was applied and the
affected module (`drm`) built clean with `-Werror` (see fix_build.log).

## Fix

drm_auth.c:197-201: restore the exclusivity check (uncomment ret=-EINVAL; goto out_unlock) so SET_MASTER is rejected when dev->master is already held, preventing the refcount leak/mastership theft.

The standalone, git-apply-able diff is `fix.diff`.