• File: sys/dev/drm/drm_atomic_uapi.c
• Lines: 1083, 1090, 1108, 1122, 1126, 1127, 1132, 1206, 1213, 1216
• Severity: Medium
• CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U:C:N/I:N/A:H
• CWE: CWE-401 Missing Release of Memory after Effective Lifetime
• Confidence: certain

Summary

When a DRM atomic commit requests an out-fence pointer (OUT_FENCE_PTR CRTC property) without also setting DRM_MODE_PAGE_FLIP_EVENT, prepare_signaling() allocates a drm_pending_vblank_event and stores it in crtc_state->event.

If a subsequent allocation in the same loop fails before crtc_state->event->base.fence is assigned (most reliably: sync_file_create() at drm_atomic_uapi.c:1055, which in DragonFlyBSD is a stub that always returns NULL — see sys/dev/drm/include/linux/sync_file.h:48-53), the function returns the error.

complete_signaling() then iterates CRTC states but its cleanup predicate event && (event->base.fence || event->base.file_priv) at drm_atomic_uapi.c:1213 is false (neither field was set), so the event is never freed.

The driver-level atomic_destroy_state helper (__drm_atomic_helper_crtc_destroy_state at drm_atomic_helper.c:3562-3587) only frees state->commit->event, not state->event itself, so the ~128-byte drm_pending_vblank_event is orphaned on every failing request.

Root cause

prepare_signaling() at drm_atomic_uapi.c:1083-1090 allocates an event as soon as either DRM_MODE_PAGE_FLIP_EVENT or a non-NULL fence_ptr is present, then unconditionally stores it in crtc_state->event.

Later, the fence block at drm_atomic_uapi.c:1108-1133 calls krealloc (1112), drm_crtc_create_fence (1122), and setup_out_fence (1126); setup_out_fence can return -ENOMEM at sync_file_create failure (drm_atomic_uapi.c:1055-1057).

On that path the post-increment (*num_fences)++ has already executed, so the fence_state[] entry is cleaned up by complete_signaling at lines 1222-1232, but the line crtc_state->event->base.fence = fence at drm_atomic_uapi.c:1132 is never reached, leaving the event with both fence and file_priv NULL.

complete_signaling() at drm_atomic_uapi.c:1206-1217 only calls drm_event_cancel_free() when (event->base.fence || event->base.file_priv) is true (line 1213); the comment at 1208-1211 explains this is intended to avoid double-freeing events allocated by drm_atomic_helper_setup_commit(), but the predicate mis-classifies the prepare_signaling()-allocated but never-fully-initialized event as belonging to the helper, and so it leaks.

Threat

Any local user able to obtain DRM master status (typical for the active GUI session via logind/console, or anyone who can open /dev/dri/card0 first when no other master is active) and who has enabled DRM_CLIENT_CAP_ATOMIC (drm_atomic_uapi.c:1260) can trigger this leak in a tight loop.

The cost per iteration is one ioctl plus the allocation of a drm_pending_vblank_event (128 bytes plus allocator overhead).

In DragonFlyBSD specifically the leak is deterministic because sync_file_create() is an unconditional NULL-returning stub (sys/dev/drm/include/linux/sync_file.h:48-53), so 100% of atomic commits carrying OUT_FENCE_PTR will leak.

At a modest rate of 100k ioctls/sec an attacker can leak ~12-15 MB/sec; sustained, this exhausts kernel heap and produces global allocation failures (denial of service for the whole system, not just the DRM subsystem).

There is no privilege escalation and no memory disclosure — the impact is availability only.

Exploit / PoC

/* leak_atomic_event.c - build: cc -O2 -o leak leak_atomic_event.c */
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <dev/drm/drm.h>
#include <dev/drm/drm_mode.h>

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

    uint64_t cap = DRM_CLIENT_CAP_ATOMIC;
    if (ioctl(fd, DRM_IOCTL_SET_CLIENT_CAP, &cap)) { perror("setcap"); return 1; }

    /* Enumerate CRTCs, find OUT_FENCE_PTR prop_id, then loop atomic commit.
     * See finding markdown for full listing. */
    /* ... */
    return 0;
}

Each failing ioctl returns -ENOMEM but leaks one event.

Run vmstat -m in parallel and observe allocations growing monotonically without bound; process can be left running indefinitely and will eventually trigger system-wide ENOMEM.

Recommended fix

Mirror the upstream fix (Abhishek Kumar, dri-devel 2026-03-29, syzkaller-reported). complete_signaling() must also free events that were allocated by prepare_signaling() but never had fence or file_priv attached.

Helper-allocated events are reliably distinguished by the presence of a completion callback, so the absence of event->base.completion identifies our orphaned events:

--- a/sys/dev/drm/drm_atomic_uapi.c
+++ b/sys/dev/drm/drm_atomic_uapi.c
@@ -1213,6 +1213,17 @@ static void complete_signaling(struct drm_device *dev,
        if (event && (event->base.fence || event->base.file_priv)) {
            drm_event_cancel_free(dev, &event->base);
            crtc_state->event = NULL;
+       } else if (event && !event->base.completion) {
+           /*
+            * The event was allocated by prepare_signaling()
+            * but an error path was hit before the event got
+            * fully set up (fence or file_priv assigned).
+            * Events from drm_atomic_helper_setup_commit()
+            * always have completion set, so checking for its
+            * absence safely distinguishes our events.
+            */
+           kfree(event);
+           crtc_state->event = NULL;
        }
    }

The same defect does not exist on the connector writeback out-fence path (drm_atomic_uapi.c:1138-1175) because that path does not allocate a drm_pending_vblank_event — it only allocates a drm_writeback_job whose lifetime is tied to the connector state via drm_atomic_set_writeback_fb_for_connector() and is released by the connector atomic_destroy_state helper.

As a separate, independent hardening consideration, DragonFlyBSD should either implement sync_file_create/sync_file_get_fence or have them return -ENOSYS-style errors that propagate as -ENOSYS rather than -ENOMEM, so the OUT_FENCE_PTR/IN_FENCE_FD features fail cleanly upstream of prepare_signaling() rather than silently breaking every atomic commit that touches an out-fence. That is a functional issue outside the scope of this security finding.