# VERDICT -- DF-2018 (Low)

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

**Impact:** DRM_MASTER privilege revocation defeated (logic); HW-gated (needs DRM/GPU), source-confirmed

**Confidence:** likely

## Mechanism (source-traced)

drm_is_current_master (drm_auth.c:333-336) returns fpriv->is_master -- a sticky bit set once at drm_new_set_master (drm_auth.c:160), never cleared when dev->master is reassigned. Modern upstream Linux uses 'fpriv->allowed_master || fpriv->master == fpriv->minor->dev->master'. Once an fd has is_master=1 it permanently passes every DRM_MASTER ioctl permit check (drm_ioctl.c:547-549) even after the device master moves to a different fd.

## 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:333-336: return fpriv->is_master && fpriv->master == fpriv->minor->dev->master so authority tracks the live device master pointer, not a sticky flag.

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