devfs_spec_open clone path: EPERM/EBUSY early returns after securelevel/mounted-RW checks leak the cloned vp exclusively locked and referenced forever
| Field | Value |
|---|---|
| ID | DF-3019 |
| Status | new |
| Severity | Low |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:L |
| CWE | CWE-401 (locked vnode leak) |
| File | sys/vfs/devfs/devfs_vnops.c |
| Lines | 1006-1024 (cf. correct handling :992-998, :1063-1064) |
| Area | vfs/devfs |
| Confidence | likely |
| Discovered | 2026-09-02 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | base:vfs |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
After a successful clone (devfs_allocv returned the new vp locked+ref'd and ap->a_vp was swapped at :933-935), the D_DISK write-open security checks at :1006-1024 'return EPERM/EBUSY' directly: the cloned vp keeps devfs_allocv's reference and EXCLUSIVE lock forever (vn_open's caller only balances the original vp). The vnode can never be reused — permanent vnode leak + permanently locked vnode (any later vget on it hangs). Realistic only for cloned D_DISK devices opened FWRITE with securelevel>=2 or mounted RW (vn(4) is an autoclone D_DISK) — root-only devices, hence Low; but each triggering open permanently burns a vnode. Not executed (needs root + a configured vn device). Fix: add 'if (orig_vp) vput(vp);' before each of the three returns.
Timeline
- 2026-09-02 Discovered during pass-2 audit of devfs_vnops.c (GLM 5.3).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-3019 · 8 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 332 B | ↓ raw | |
| VERDICT.md | — | 1.2 KB | ↓ raw | |
| df3019.c | — | 722 B | view raw | |
| env.txt | — | 248 B | view raw | |
| fix.diff | — | 122 B | view raw | |
| manifest.json | — | 566 B | view raw | |
| run.log | — | 229 B | view raw | |
| verdict.json | — | 1.5 KB | view raw |
DF-3019 - devfs_spec_open clone path: EPERM/EBUSY after clone leaks cloned vp locked+referenced
Severity Low | verdict: not_reproduced | impact: none
Reproduce
Sources in this directory; build with cc -O2 -o <bin> <src> -pthread on the guest.
See VERDICT.md for the full narrative and run.log for the decisive output.
DF-3019 verification
Kernel: DragonFly dfbsd 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64
Reproduced the precondition exactly: kern.securelevel raised to 2, then 20 open(/dev/vn, O_WRONLY) calls - all return EPERM from the D_DISK+FWRITE check (devfs_vnops.c:1006-1010) and each creates a fresh vn unit (vn7, vn8, ... appear in /dev). However the claimed permanent vnode leak is NOT observable: debug.numvnodes stayed flat at 98371 across the run and the created unit vnodes remain fully usable (ls and read-only open of /dev/vn7 succeed immediately - a permanently EXCLUSIVE-locked vp would block vget forever). On this guest the EPERM path did not strand a locked vnode.
Kernel references
Fix
See fix.diff.
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.
Fix verification
not_testableConfirmed kernel references
Detail
Evidence (decisive lines)
VERDICT.md + run.log + sources
PoC changes
adjusted from finding sketch to guest syscall/layout reality
Verified recommended fix
diff: vput(vp) before the three early returns in the D_DISK write-open block (mirroring the :992-998 EALREADY cleanup).
Verdict
Reproduced the precondition exactly: kern.securelevel raised to 2, then 20 open(/dev/vn, O_WRONLY) calls - all return EPERM from the D_DISK+FWRITE check (devfs_vnops.c:1006-1010) and each creates a fresh vn unit (vn7, vn8, ... appear in /dev). However the claimed permanent vnode leak is NOT observable: debug.numvnodes stayed flat at 98371 across the run and the created unit vnodes remain fully usable (ls and read-only open of /dev/vn7 succeed immediately - a permanently EXCLUSIVE-locked vp would block vget forever). On this guest the EPERM path did not strand a locked vnode.
No comments yet.