DF-2222 — wait_for_completion_interruptible spins forever on signal (drm/linux_completion)

Verdict: NOT REPRODUCED (HW-gated); REAL BUG IN SOURCE (defense-in-depth fix warranted)

Hardware gate (why the PoC cannot run on this guest)

The triggering ioctls (DRM_IOCTL_MODE_ATOMIC, i915 PSR) require a DRM/KMS GPU with an attached /dev/dri/card0. The audit QEMU/KVM guest has only the framebuffer-style vgapci0 (class 0x030000, Bochs/QEMU std VGA chip 0x11111234) and no DRM driver attaches:

$ pciconf -l | grep vga          # vgapci0@pci0:0:2:0: class=0x030000 ... chip=0x11111234
$ ls /dev/dri* 2>&1              # /dev/drm* /dev/dri*: No such file or directory
$ ls /dev/agpgart 2>&1           # No such file or directory
$ kldstat                        # only kernel + ehci.ko + xhci.ko (no drm/i915/amdgpu)

With no /dev/dri/card0, the DRM_IOCTL_MODE_ATOMIC and i915 PSR paths that reach wait_for_completion_interruptible() are unreachable by any user. The unprivileged maxx user cannot open a non-existent device. The bug is also exercisable in principle from any in-tree DRM driver (the function is generic Linux-completion glue), but none of those drivers have a device to attach on this guest.

Source trace — the bug is REAL (sys/dev/drm/include/linux/completion.h)

__wait_for_completion_generic() (completion.h:78-116):

lockmgr(&c->wait.lock, LK_EXCLUSIVE);
while (c->done == 0 && !timeout_expired) {
    ret = lksleep(&c->wait, &c->wait.lock, flags, "lwfcg", timeout);
    switch(ret) {
    case EWOULDBLOCK:
        timeout_expired = true;
        ret = 0;
        break;
    case ERESTART:                  /* signal pending (PCATCH) */
        ret = -ERESTARTSYS;
        break;                      /* breaks the SWITCH only, NOT the while */
    case 0:
        awakened = true;
        break;
    /* EINTR: no case at all -> ret stays stale, loop continues */
    }
}

On ERESTART (signal arrived during a PCATCH sleep) the code sets ret = -ERESTARTSYS but the break exits only the switch; the while predicate (c->done == 0 && !timeout_expired) is unchanged, so the loop re-enters lksleep. Because tsleep() with PCATCH returns immediately without blocking whenever a signal is pending (kern_synch.c CURSIG path does not consume the signal), the loop becomes a tight, CPU-bound kernel spin. The process cannot be interrupted by SIGTERM/SIGINT/SIGKILL (deferred to a user boundary that is never reached). EINTR has no case at all, so ret is stale and the loop likewise spins. (The wrapper at linux_completion.c:38-46 only maps the final ret; it cannot break the inner loop.)

Secondary issue: awakened is set true on a case 0 and never reset, so a spurious-wakeup-then-real-timeout iteration falsely reports remaining_jiffies as success.

The claim's reachability via DRM_IOCTL_MODE_ATOMIC (drm_atomic_helper.c:2627/2638/2649) and i915 PSR (intel_psr.c:869) is accurate for any system with a DRM driver attached.

Exploit chain status

Not pursuable — primitive (uninterruptible CPU-bound spin / unkillable thread, a local DoS holding DRM/GEM resources) is behind absent DRM hardware (valid Phase-6 hard blocker: dead path at runtime, no harness on this guest). On a DRM-equipped host the unprivileged-video-group trigger is real.

PoC changes

None. /dev/dri/card0 absent; verified by source trace only.

Recommended fix

On ERESTART/EINTR, break out of the while loop (not just the switch), and handle EINTR. See fix.diff (supersedes finding proposal by also handling the missing EINTR case and the sticky-awakened false-success).