DF-4454 VERDICT — evdev client/evdev lifetime UAF across driver teardown

Status: reproduced. Impact: kernel memory corruption via dangling `struct evdev_dev *' (demonstrated cross-object write) + system wedge (DoS). Confidence: certain.

Root cause (line-accurate)

evdev_unregister() (sys/dev/misc/evdev/evdev.c:366-406) revokes all clients and destroys the cdev, but nothing waits for the open file descriptors (each holding a struct evdev_client' withclient->ec_evdev' pointing back at the evdev) to go away. evdev_free() (evdev.c:113-121) then immediately `kfree(evdev, M_EVDEV)'.

Three use-after-free arms:

1. evdev_dtor (cdev.c:160-173): every later close(2) of a stale fd executes `EVDEV_LOCK(client->ec_evdev)' — lockmgr on freed memory.
2. evdev_write (cdev.c:233-265): evdev' is cached at syscall entry and the event loop never re-checksclient->ec_revoked', so an in-flight multi-megabyte write keeps calling `evdev_inject_event()' on the freed struct for the whole buffer (uiomove sleeps make the window seconds wide).
3. evdev_open (cdev.c:98-158): evdev = dev->si_drv1' is read before a sleepingkmalloc(M_WAITOK)'; the re-check under EVDEV_LOCK operates on an evdev that may already be freed (the comment "Avoid race with evdev_unregister" is insufficient — the lock itself is in freed memory).

Contrast with FreeBSD, whose evdev_unregister' usesdestroy_dev()', which drains open references before the caller proceeds to free. The DragonFly port replaced that with `dev_ops_remove_minor()' (cdev.c:733-742 → kern_device.c:649 → devfs async message), which does NOT wait.

Reproduction on the audit guest

Guest: DragonFly 6.5-DEVELOPMENT #0 Thu Jul 2 06:02:54 UTC 2026 (X86_64_GENERIC), QEMU/KVM. ukbd (compiled in, EVDEV_SUPPORT) attached via -device piix3-usb-uhci -device usb-kbd.

Sequence: open /dev/input/event4 → start 8-64 MB write of {EV_KEY,KEY_Q,v}/{EV_SYN,SYN_REPORT,0x1337} pairs → QEMU monitor device_del kbd1' (ukbd_detach → evdev_free, write still in flight) →device_add usb-kbd' (new evdev_dev re-uses the freed block) → reader on the re-created event4.

Observed (see run.log):

• 3 of 3 well-timed rounds delivered magic events to the NEW device's client ring (19, 5, 2 events with value=0x1337) — cross-object event injection through the dangling pointer. Nobody wrote 0x1337 to the new fd.
• Full 64 MB write(2) returned success although the device was deleted mid-call (~2.79M events injected through freed/reused memory).
• One in-flight write failed with EINVAL once the reallocated evdev's flag bitmap changed under the stale loop — direct evidence the loop was reading foreign memory.
• 6-cycle device_del/device_add churn with a 256 MB write in flight: hard system wedge — ssh unresponsive, serial console silent (wedge_serial_tail.txt), QEMU at 87-394 %CPU (vCPU livelock on corrupted lockmgr state). The guest recovered only after several minutes.
• Closing stale fds (dtor arm) exercised lockmgr-on-freed-memory; on the baseline kernel this stayed silent (freed block retains stale lock values), it is the same UAF write primitive.

Why impact is not uid=0

Opening /dev/input/eventN requires passing `caps_priv_check_self(SYSCAP_RESTRICTEDROOT)' (cdev.c:110) — i.e. root — and the teardown trigger is a privileged unload or physical USB unplug. So this is a root/physical-triggered kernel UAF, not an unprivileged escalation. The demonstrated primitive is a stale-fd write into re-allocated kernel memory (attacker-controlled {type,code,value} triples against whichever object re-uses the block; M_EVDEV size class is shared by all evdev providers and client rings), plus lockmgr corruption of freed slab memory on close. Realistic ceiling on default configs: kernel memory corruption / hard DoS from device removal while a root compositor holds the node.

Fix validation

fix.diff (authored after reproduction; applied to a guest /usr/src copy, kernel rebuilt with `make nativekernel KERNCONF=X86_64_GENERIC', installed, rebooted — kernel md5 54c1a462e7f1c6bc303929ac0cd99ac3):

• refcount ev_refs' on evdev_dev: 1 alloc ref (dropped in evdev_free), 1 cdev ref (dropped under the newevdev_master_lock' when si_drv1 is NULLed in evdev_unregister), 1 ref per open fd (dropped in evdev_dtor); kfree deferred to the last unref.
• `evdev_master_lock' (master → state lock order) closes the evdev_open TOCTOU: si_drv1 is published/cleared and ref'd under it.
• evdev_write re-checks `client->ec_revoked' every event.
• evdev_dtor drops its reference before kfree(client)'. Two earlier fix iterations of mine were themselves buggy (the compiler sinks theclient->ec_evdev' load past kfree — UB — causing NULL unref panics); documented in fix_iter1_panic.txt. Lesson recorded for the maintainer: keep the unref strictly before the client free.

Patched-kernel results (fixrun3/4/5/fixstress):

• in-flight writes abort at the first revoke (ENODEV, or EBADF from the devfs layer on the detached cdev) — no injection through freed memory;
• zero magic events on the re-created device across 4 rounds + the identical 6-cycle churn that wedged the baseline — guest stayed up;
• stale fds close with no panic; the dtor runs against reference-pinned memory;
• functional smoke test: QEMU `sendkey a/b' events flow to a reader on event4 unchanged (correct 24-byte input_event records).

fix_status: fixed (baseline_reproduced=1, patched_reproduced=0).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.