[RFC] drm/lima: context initialization after handle publication

From: Sang-Hoon Choi

Date: Mon Sep 21 2026 - 12:35:05 EST


Hi,

I would like to report a possible context lifetime race between
DRM_IOCTL_LIMA_CTX_CREATE and DRM_IOCTL_LIMA_CTX_FREE on a shared file.

The source reviewed is mainline commit
5dd1818b15d98d4a20806cd00b1b40320b06004f.

lima_ctx_create() publishes ctx with xa_alloc() before setting ctx->pid
and ctx->pname. It does not hold mgr->lock. lima_ctx_free() takes that
mutex, erases the handle, and drops the context reference.

An empty context manager allocates handle 0 first. A second thread
sharing the file can therefore try that handle without waiting for the
create ioctl to return. If free runs after publication and no other
reference has been acquired, the following order appears possible:

lima_ctx_create() lima_ctx_free(id = 0)
----------------- ---------------------
xa_alloc(..., ctx, ...)
xa_erase(..., 0)
kref_put(...)
kfree(ctx)
ctx->pid = ...
get_task_comm(ctx->pname, ...)

The two Lima ioctl handlers do not add serialization around these calls,
and drm_ioctl_kernel() invokes the handler without a common ioctl mutex.
Both ioctls permit render-node access. This describes a source-level
use-after-free candidate; it has not been demonstrated on hardware.

A draft holds mgr->lock across xa_alloc() and the remaining initialization.
It was compile-checked as lima_ctx.o with W=1 in an x86 allmodconfig build
at the commit above and passed checkpatch. Moving pid/pname initialization
before xa_alloc() would also remove the post-publication accesses and may
be a simpler fix. That alternative has not been compile-tested here.

There is no Mali4xx runtime reproducer or KASAN trace. Would initializing
these fields before publication be the preferred fix, or is there a
lifetime guarantee elsewhere that rules out this interleaving?

Reported-by: Changyul Lee <lcy8047@xxxxxxxxx>
Assisted-by: LLM

Thanks,
Sang-Hoon Choi