DragonFlyBSD Kernel Audit
← triage · dashboard
DF-3018

spec VOP dispatch (devfs_spec_read/write/ioctl/kqfilter, D_QUICK close) calls dev_d* on vp->v_rdev with no cdev reference and the vnode unlocked — vfs_timestamp(&node->atime) after teardown is a UAF write if the device dies during the dispatch

Field Value
ID DF-3018
Status new
Severity Low
CVSS 3.1 CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:N/I:H/A:H
CWE CWE-667 / CWE-416
File sys/vfs/devfs/devfs_vnops.c
Lines 1099-1111, 1704-1718, 1739-1755, 1775-1787, 1803-1812
Area vfs/devfs
Confidence likely
Discovered 2026-09-02
Pass 2 (GLM 5.3 second pass)
Bucket memcorrupt
Reported pending
Known CVE none
CVE match novel

Summary

Unlike the devfs_fo_ fileops (which take reference_dev/release_dev around dev_dread/dev_dwrite/dev_dioctl/dev_dkqfilter), the VOP-layer twins cache dev=vp->v_rdev, vn_unlock(vp), dispatch, relock, then dereference the cached node (vfs_timestamp writes). devfs_freep can vget the unlocked vp, detach v_rdev and free both node and cdev mid-dispatch: driver d_ then runs on a freed cdev and the timestamp writes hit freed node memory. Unpriv reachability today is limited: direct VOP_READ/WRITE/IOCTL on device vnodes is only reachable via /dev/tty ctty forwarding, and pty destruction is gated by the pti refcount protocol, console ttys are static — no live unpriv trigger constructed. The gap bites for any driver that destroys its cdev during these dispatches (root-mediated revoke/detach, or future last-close-destroy drivers). Defense-in-depth fix matching the fo_* layer: reference_dev(dev) before vn_unlock, release_dev after relock, re-cache node after relock before vfs_timestamp; same for the D_QUICK close branch.

Timeline

  • 2026-09-02 Discovered during pass-2 audit of devfs_vnops.c (GLM 5.3).

Discussion (0)

No comments yet.