vkernel64: sys_umtx_sleep() calls blocking uservtophys() inside a critical section — LWKT lock-protocol violation
| Field | Value |
|---|---|
| ID | DF-2958 |
| Status | new |
| Severity | Low |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L |
| CWE | CWE-667 Improper Locking |
| File | sys/kern/kern_umtx.c |
| Lines | 199-216 (blocker: vkernel64/platform/pmap.c:366-392) |
| Area | kern + vkernel64 |
| Confidence | likely |
| Discovered | 2026-09-02 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | base:kern |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
On the vkernel64 platform, kern_umtx.c:216 re-resolves the physical address via uservtophys() INSIDE the crit_enter() begun at :199. The vkernel64 implementation calls vm_fault_page(..., VM_FAULT_NORMAL, ...), which blocks on non-resident/busy/COW pages. Blocking inside an LWKT critical section violates the core protocol ('This code can't block ... or bad things will happen') and can deadlock or trip the switch-from-critical-section assertions. The pc64 implementation is a lockless PTE read and is safe; only vkernel64 diverges. Unprivileged process inside a vkernel64 kernel triggers repeated blocking page faults from within a critical section (e.g. fork()/mprotect() COW break racing between the initial translation at :147 and the in-crit re-check at :216) under memory pressure → vkernel panic/deadlock — availability only, vkernel64 deployments only. Not Phase-V verified (pc64 guest; nested vkernel disproportionate to a Low vkernel-only DoS). Fix: make vkernel64's uservtophys a non-blocking advisory translation matching pc64 semantics (row sketch).
Timeline
- 2026-09-02 Discovered during pass-2 audit of kern_umtx.c (GLM 5.3).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-2958 · 5 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 593 B | ↓ raw | |
| VERDICT.md | — | 1.8 KB | ↓ raw | |
| env.txt | — | 401 B | view raw | |
| manifest.json | — | 450 B | view raw | |
| verdict.json | — | 1.5 KB | view raw |
DF-2958 PoC evidence pack
What
vkernel64: sys_umtx_sleep calls blocking uservtophys inside a critical section (LWKT protocol violation).
Build
(none)
Run
(none)
Expected
static confirmation (vkernel64 platform not deployable in nested guest)
Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:04 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 All logs are full untrimmed captures unless noted. fix.diff is the git-apply-able verified fix (authored after verification; never applied to the audit tree).
DF-2958 - verification verdict
Status: not_reproduced | reproduced: 0 | impact: denial_of_service | confidence: likely
Source-certain, platform-unreachable on this guest: kern_umtx.c:199 crit_enter() ... :216 uservtophys() inside the critical section is confirmed; the pc64 implementation is a lockless PTE read (safe) but the vkernel64 implementation (vkernel64/platform/pmap.c:366-392) calls vm_fault_page(..., VM_FAULT_NORMAL, ...) which can block (vm_wait_pfault/vm_wait paths), violating the LWKT critical-section protocol the tsleep_interlock path requires. A vkernel64 instance cannot be deployed inside the nested QEMU pc64 guest within scope; verification is static. Availability-only, vkernel64 deployments only.
Evidence pointers
kern_umtx.c:199-216 confirmed; blocking fault path in vm_fault.c documented
Kernel references
PoC changes vs the filing sketch
nested vkernel64 not deployable; static verification
Fix
recommendation: non-blocking advisory translation in vkernel64 uservtophys matching pc64 semantics
fix status: not_testable
vkernel64 pmap fix not authored (out of scope of the pc64 fix-all build); documented
Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:04 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64
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.
(No fix.diff for this item: documented recommendation only - see Fix above.)
Fix verification
not_testablevkernel64 pmap fix not authored (out of scope of the pc64 fix-all build); documented
Confirmed kernel references
Detail
Evidence (decisive lines)
kern_umtx.c:199-216 confirmed; blocking fault path in vm_fault.c documented
PoC changes
nested vkernel64 not deployable; static verification
Verified recommended fix
non-blocking advisory translation in vkernel64 uservtophys matching pc64 semantics
Verdict
Source-certain, platform-unreachable on this guest: kern_umtx.c:199 crit_enter() ... :216 uservtophys() inside the critical section is confirmed; the pc64 implementation is a lockless PTE read (safe) but the vkernel64 implementation (vkernel64/platform/pmap.c:366-392) calls vm_fault_page(..., VM_FAULT_NORMAL, ...) which can block (vm_wait_pfault/vm_wait paths), violating the LWKT critical-section protocol the tsleep_interlock path requires. A vkernel64 instance cannot be deployed inside the nested QEMU pc64 guest within scope; verification is static. Availability-only, vkernel64 deployments only.
No comments yet.